I added a warning to the documentation. Can someone with commit rights have a look at it and apply it? This would have definitely saved us a lot of time. And I am sure this will help other people too.
Cheers, Alexey On Wed, May 2, 2012 at 1:28 PM, David Allsopp <dra-n...@metastack.com> wrote: > 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 -- dr. Alexey Rodriguez Yakushev Vector Fabrics included in EE Times 'Silicon 60' list of emerging startups O +31 (0)40 8200960 | D + 31 (0)40 8200974 | F +31 (0)40 8200979 Vonderweg 22, 5616 RM | Eindhoven | The Netherlands www.vectorfabrics.com | ale...@vectorfabrics.com -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
warning_exception.patch
Description: Binary data
