caml-list - the Caml user's mailing list
 help / color / Atom feed
Subject: [Caml-list] C, threads, callbacks, and corrupted local_roots
Date: Thu, 20 Jun 2019 20:03:07 +0200
Message-ID: <> (raw)

[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]

Hello !

I have a programs which entry point is in C++ and that spawn a few threads, some of which are calling back some OCaml code. 
My understanding is that for this to work, one must only follow those rules (in addition to the usual "how to leave in peace with the GC" rules:

1. call caml_startup(argv) before any OCaml code or any other function from the OCaml runtime is run;

2. for each thread that will eventually run some OCaml code (anything that could call the GC (and also, possibly, do anything with signals)), call caml_c_thread_register before;

3. before a thread terminates and another thread runs the OCaml GC, call (from that terminating thread) caml_c_thread_unregister (it is not clear exactly why to be honest, as a finished thread should have no root left)

What is a bit unclear is how thread registering and caml_startup are supposed to deal with the giant lock. From testing and
reading the code, it seems that caml_c_thread_(un)register expects the giant lock to be released, which caml_startup does not do, so calling caml_release_runtime_system right after caml_startup seems in order (and therefore reacquiring it before calling back to OCaml).

Neither is it clear to me how to declare local roots in the function registering the thread (more specifically: should caml_c_thread_register be called first, then a new block created and CAMLparam and friends be called now that the current root list is initialized?); But in the exemple below it does not matter as there are no values requiring such protection.

Yet, whatever I try, I get a crash in the Gc when it's scaninng the roots in caml_do_local_roots, with a corrupted local_root pointer that is suspiciously small (few hundred bytes, frequently but not always just 0xfff). I am not certain about those values though, as I'm not using a debug runtime (opam had such debug variants for a couple of old ocaml versions but not any longer it seems)

Thankfully, the attached minimal example dies in the exact same circumstances.

Do anyone know what I am doing wrong?

[-- Attachment #2: Makefile --]
[-- Type: application/octet-stream, Size: 424 bytes --]

[-- Attachment #3: --]
[-- Type: application/octet-stream, Size: 217 bytes --]

[-- Attachment #4: b.c --]
[-- Type: application/octet-stream, Size: 704 bytes --]

             reply index

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-20 18:03 rixed [this message]
2019-06-21  7:30 ` Sébastien Hinderer
2019-06-21 10:51   ` rixed
2019-06-21 11:38     ` Sébastien Hinderer
2019-06-21 12:21       ` rixed
2019-06-21 14:00         ` Sébastien Hinderer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

caml-list - the Caml user's mailing list

Archives are clonable:
	git clone --mirror
	git clone --mirror

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone