From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 1C5C17FE07 for ; Wed, 3 Feb 2016 11:54:21 +0100 (CET) IronPort-PHdr: 9a23:1zo25h1ab3KmZa6KsmDT+DRfVm0co7zxezQtwd8ZsegQKPad9pjvdHbS+e9qxAeQG96LtLQd1aGO6ujJYi8p39WoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6kO74TNaIBjjLw09fr2zQd6NyZ3pnLjrs7ToICx2xxOFKYtoKxu3qQiD/uI3uqBFbpgL9x3Sv3FTcP5Xz247bXianhL7+9vitMU7q3cY6Lod8JtLWKD+N7kjQKZDRGAtOmUxocnqrgXrTA2V53JaXH9AwTRSBA2QxxHgX4zttTP6gcrj1ySAdZn9Tao1Qiil96ctSBjlhyodHyIktWvakMhxiuRXrUTy9FRE34fIbdTNZ7JFdaTHcIZCSA== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=christoph.hoeger@tu-berlin.de; spf=None smtp.mailfrom=christoph.hoeger@tu-berlin.de; spf=None smtp.helo=postmaster@mail.tu-berlin.de Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of christoph.hoeger@tu-berlin.de) identity=pra; client-ip=130.149.7.33; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="christoph.hoeger@tu-berlin.de"; x-sender="christoph.hoeger@tu-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of christoph.hoeger@tu-berlin.de) identity=mailfrom; client-ip=130.149.7.33; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="christoph.hoeger@tu-berlin.de"; x-sender="christoph.hoeger@tu-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail.tu-berlin.de) identity=helo; client-ip=130.149.7.33; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="christoph.hoeger@tu-berlin.de"; x-sender="postmaster@mail.tu-berlin.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CFAADg27FWnCEHlYJehHmIW7Mxh088EAEBAQEBAQEBEAEBAQEBCAsJCSEugi2CPgQLAUU2AgUWCwILAwIBAgFLDQYCAQGIFwSgbo9bjzh7kQCBOgWWcYETlVaFVY5AN4FhAQsBQBEIgUlpiWsBAQE X-IPAS-Result: A0CFAADg27FWnCEHlYJehHmIW7Mxh088EAEBAQEBAQEBEAEBAQEBCAsJCSEugi2CPgQLAUU2AgUWCwILAwIBAgFLDQYCAQGIFwSgbo9bjzh7kQCBOgWWcYETlVaFVY5AN4FhAQsBQBEIgUlpiWsBAQE X-IronPort-AV: E=Sophos;i="5.22,389,1449529200"; d="scan'208";a="162767713" Received: from mail.tu-berlin.de ([130.149.7.33]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Feb 2016 11:54:14 +0100 X-tubIT-Incoming-IP: 91.66.48.164 Received: from ip5b4230a4.dynamic.kabel-deutschland.de ([91.66.48.164] helo=[192.168.178.42]) by mail.tu-berlin.de (exim-4.76/mailfrontend-8) with esmtpsa [UNKNOWN:AES128-SHA:128] for id 1aQv4e-0001Kl-kL; Wed, 03 Feb 2016 11:54:13 +0100 To: caml users From: =?UTF-8?Q?Christoph_H=c3=b6ger?= X-Enigmail-Draft-Status: N1110 Organization: =?UTF-8?Q?Technische_Universit=c3=a4t_Berlin?= Message-ID: <56B1DC54.1060109@tu-berlin.de> Date: Wed, 3 Feb 2016 11:54:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.2.3.104815 X-PMX-Spam: Gauge=IIIIIII, Probability=0%, Report='' Subject: [Caml-list] Save callbacks from OCaml to C Seems this problem bugs me forever... I have a scenario, where some C-stubs call back into OCaml, so the stack (growing downwards) looks like this: caml_foo ... /* OCaml control ends here */ ... c_stub ... c_library_routine (user_data; &callback_wrapper, ...) ... c_callback_wrapper(user_data; ...) /* OCaml controlled again */ caml_callbackN(user_data->closure, ....) The pattern should be somewhat familiar to anyone who has ever combined C and OCaml in a non-trivial way: I store the actual ocaml callbacks in the heap-allocated user_data structure, which is guaranteed to be passed to the callbacks by the c-library. The callback wrapper then wraps all arguments and uses caml_callback on these closures. The callback wrapper is a pure C-routine, i.e. no CamlParamN or CamlLocalN macros are used here. But still, the garbage collector runs amok. After a while I see the user_data pointer set to 0x0! How can that be, how can it overwrite a stack value of a calling C-routine? Here is the real callback: void g(void* user_data, double t, double const *x, double *g) { const struct interface_data* data = ((struct interface_data*)user_data); static long count = 0; count++; /* Wrap the values in fresh big arrays */ value ml_t = caml_copy_double(t); value ml_x = caml_ba_alloc_dims(CAML_BA_FLOAT64 | CAML_BA_C_LAYOUT, 1, (double*)x, data->qs->n); value ml_g = caml_ba_alloc_dims(CAML_BA_FLOAT64 | CAML_BA_C_LAYOUT, 1, g, data->qs->mc); /* call the OCaml callback */ caml_callback3(data->g, ml_t, ml_x, ml_g); } Is there anything obvious, I am doing wrong? -- Christoph Höger Technische Universität Berlin Fakultät IV - Elektrotechnik und Informatik Übersetzerbau und Programmiersprachen Sekr. TEL12-2, Ernst-Reuter-Platz 7, 10587 Berlin Tel.: +49 (30) 314-24890 E-Mail: christoph.hoeger@tu-berlin.de