Re: [Caml-list] Nested callbacks?

[Dmitry Bely <dmitry.bely@gmail.com>]

On Tue, Jul 5, 2011 at 9:31 PM, Xavier Leroy <Xavier.Leroy@inria.fr> wrote:
> On 07/05/2011 06:30 PM, Thomas Fischbacher wrote:
>>
>> Dmitry Bely wrote:
>>
>>> Is it allowed to call a Caml closure from C (caml_callbackN_exn), that
>>> calls another Caml closure internally (also with caml_callbackN_exn)?
>>
>> I strongly hope so! If this did not work, that would have disastrous
>> consequences for the tight integration of Caml and Python which we are
>> using. (Well, so far, we never encountered a problem with that. And the
>> documentation does not warn against doing this - so, should it not work,
>> that should be considered a bug.)
>
> Indeed, it should work, and I see no reason why nested callbacks could
> fail.  Callbacks do save some Caml-specific state and restore it
> before returning, but they use the stack to do so, so they should be
> reentrant.  Please file a bug report if you find out they are not.

Thanks. I am trying to find a memory bug in a multithreaded
application that calls bytecode Ocaml runtime from C via callbacks. I
was able to extract a test that triggers the bug. Actually it's just
an endless loop with a single callback inside that only allocates some
memory on the Ocaml heap. Interesting enough that when I have only one
Caml thread (and no Caml tick thread running), everything goes OK. But
when I register 2 threads in Ocaml runtime (one worker, one always
sleeping), thus enabling the tick thread and related preempt signal
machinery, after many cycles I get a memory bug in the worker thread:

Starting new major GC cycle
### O'Caml runtime: heap check ###
file freelist.c; line 397 ### Assertion failed: prev < bp || prev == Fl_head

(Assertion is failed because prev == bp)

As the preempt signal is also processed via Caml callback, I thought
the problem might be nested callbacks. But if they are OK - well, I
just have to continue debugging. If I find what goes wrong, of course
I will file a bug report.

- Dmitry Bely