Re: [Caml-list] Exception values may crash GC when interfacing C and Caml
Thank you Wojciech. I just added ticket 5606 [1] with the patch to the documentation. Cheers, Alexey [1] http://caml.inria.fr/mantis/view.php?id=5606 On Wed, May 2, 2012 at 9:37 PM, Wojciech Meyer wrote: > > Dear Alexey, > > Alexey Rodriguez writes: > >> 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. > > Yes, patches to the documentation are always welcome! > > Please use [1] to file a ticket and describe the change and/or propose a > patch. > > [1] http://caml.inria.fr/mantis/my_view_page.php > > Regards, > > - Wojciech -- Alexey Rodriguez Yakushev 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
Re: [Caml-list] Exception values may crash GC when interfacing C and Caml
Dear Alexey, Alexey Rodriguez writes: > 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. Yes, patches to the documentation are always welcome! Please use [1] to file a ticket and describe the change and/or propose a patch. [1] http://caml.inria.fr/mantis/my_view_page.php Regards, - Wojciech -- 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
Re: [Caml-list] Exception values may crash GC when interfacing C and Caml
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 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
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 -- 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
