From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q42BS8kM031314 for ; Wed, 2 May 2012 13:28:13 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQEAPkYoU9zfGcb/2dsb2JhbABEr3mECYIJAQEBBDpPAgEIGAoUEDIlAgQBGogEAgMHuj+QJWMElX6BEY8xgmg X-IronPort-AV: E=Sophos;i="4.75,515,1330902000"; d="scan'208";a="156380390" Received: from server1.rjmwebdesign.com (HELO relay.metastack.com) ([115.124.103.27]) by mail1-smtp-roc.national.inria.fr with ESMTP; 02 May 2012 13:28:13 +0200 Received: from romulus.metastack.com ([81.102.132.77]) by relay.metastack.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 May 2012 12:28:08 +0100 Received: from remus.metastack.local (remus.metastack.com [172.16.0.1]) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id q42BS83F030015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 May 2012 12:28:08 +0100 Received: from Remus.metastack.local ([fe80::547c:3c42:e1da:eda2]) by Remus.metastack.local ([fe80::547c:3c42:e1da:eda2%10]) with mapi id 14.02.0283.003; Wed, 2 May 2012 12:28:08 +0100 From: David Allsopp To: Alexey Rodriguez , "caml-list@inria.fr" Thread-Topic: [Caml-list] Exception values may crash GC when interfacing C and Caml Thread-Index: AQHNKFVkYBH0TZIC9UOJlv0USr7FQ5a2WyVw Date: Wed, 2 May 2012 11:28:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [212.183.140.61] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 172.16.0.20 X-OriginalArrivalTime: 02 May 2012 11:28:08.0656 (UTC) FILETIME=[A655ED00:01CD2856] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q42BS8kM031314 Subject: RE: [Caml-list] Exception values may crash GC when interfacing C and Caml Alexey Rodriguez wrote: > Dear all, > > We are experiencing crashes in Caml-calling C code. This happens if > garbage collection runs after Caml code has raised an exception. We now > understand why this happens but we are puzzled as to why the "Interfacing > C with Ocaml" chapter of the Ocaml manual doesn't warn about this > situation. > > Suppose you have C code that calls Caml code as follows: > > ... > CAMLparam2(v1,v2); > CAMLlocal2(...,res); > res = callback2_exn(...,v1,v2); > foobar(); > ... > > We have found that this code will crash with "Fatal error: out of memory." > if the following two things happen: > * the function called by [callback2_exn] raises an exception, and > * [foobar] triggers a garbage collection through the allocation of values > in the Caml heap. (just calling [caml_gc_full_major] is enough to cause > the crash). > > The reason for this crash is that [res] will contain an invalid pointer if > an exception is thrown. The GC follows this bogus pointer ([res] is > registered as a root by [CAMLlocal2]) which ultimately causes a crash in > the GC code. Why does [res] contain a bogus pointer? > It's not really a bogus pointer, but the lower bits are tagged in order to > denote a thrown exception. These bits are usually tested/cleared by > [Is_exception_result] and [Extract_exception]. This is already in the manual, but I agree that the requirement to do so could be stated more clearly. Section 18.7.1[1], last paragraph states "The return v of the caml_callback*_exn function **must** be tested with the macro Is_exception_result(v)". It also clearly indicates that v is only a valid [value] if Is_exception_result(v) returns false so storing the return of caml_callback*_exn in a local root and allowing the Gc to run before you update that root with the result of Extract_exception is "obviously" a Gc violation. David [1] http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html#htoc245