This is tricky code. I wonder if @Engil or @gadmm would be willing to look at this.

My gut feeling is that there may be something wrong elsewhere in the code, possibly with the semantics of registering foreign thread. It looks like a thread is running OCaml code while not being marked as the "Active" thread, which probably should not happen and probably would cause other issues than specifically this bug.

In caml_c_thread_register we set the thread from which the function is called to Active_thread->next.
ref

Active_thread not being the current running thread seems to happen in case of C threads. The following PR also seems to have fixed another problem due to that.

code ref

CAMLexport int caml_c_thread_register(void)
   th->prev = Active_thread;
   Active_thread->next->prev = th;
   Active_thread->next = th;
+  restore_runtime_state(th);

I have tried the following change and it seems to pass all tests. It updates the C thread to Active_thread when registering the thread.

(Right, I should also have cc-ed @xavierleroy obviously as someone who would know about this.)

cc-ed @xavierleroy obviously as someone who would know about this.

The systhreads code has changed too much for me to guess what's going on. It's not obvious to me that the present issue is related to #5295.

I am trying at the moment to make sense of c thread (un)registering by factoring code in common with thread creation.

Anyway, thanks for the solution to #12773, as I quickly tried to find the issue inside "register c thread", but did not find it.

@dustanddreams confirms that he can no longer reproduce the TSan use-after-free report (see #12773) with either of @Johan511's fixes. In contrast, the report still triggers on current trunk.
(For my part I can never trigger the TSan report on my machine for some reason.)

@Johan511 also tells me that on his machine the simpler example sometimes segfaults.

It's not obvious to me that the present issue is related to #5295.

I am sorry @xavierleroy the issue does seem unrelated.

I based my statement off this comment which seems to make a similar check.

PR#5295 routes to issue #5295, maybe that's the source of the confusion

I think the second route suggested at #12830 (comment) is the right one. This suggested the refactor at #12834 which fixes other bugs as well.

If I understand correctly, #12834 should have fixed the present issue, thanks to the alternate approach suggested of @Johan511 above. I am thus closing the present PR/issue. Thanks a lot for the report, the proposed fix and the suggestion for the other fix!