thread_detachThis fails to reset the thread-local sm_this pointer; so, thread_attachThis hands out a stale one.
The following call sequence from a non-D thread is sufficient to reproduce the issue:
thread_attachThis();
thread_detachThis();
thread_attachThis();
Although, the effects of the undefined behavior shows up after exercising the GC.
Pull request including a test program is coming shortly...
@MoonlightSentinel created dlang/druntime pull request #2966 "Revive 1989: Thread detach stability" fixing this issue:
- Issue 18063 - Do not pthread_detach non-D threads
- Fix issue 18063 - thread_attachThis returns dangling pointer
https://github.com/dlang/druntime/pull/2966
Comment #4 by thomas.bockman — 2021-10-05T20:35:13Z
It appears to be a race condition between `thread_attachThis` and `GC.collect`. Serializing them prevents the crash:
//////////////////////////////////////////////////
import core.sys.posix.pthread;
import core.memory;
import core.sync.mutex;
import core.thread;
import std.stdio;
enum allocCount = 1000;
enum allocSize = 1000;
enum threadCount = 100;
enum collectCount = 1000;
shared Mutex serialize;
shared static this() {
serialize = new shared Mutex;
}
extern(C) void* foo(void*)
{
serialize.lock_nothrow();
thread_attachThis();
serialize.unlock_nothrow();
scope(exit)
thread_detachThis();
foreach(_; 0..allocCount) {
new int;
new int[allocSize];
}
writeln(`foo done`);
return null;
}
void main()
{
pthread_t thread;
foreach(_; 0..threadCount) {
auto status = pthread_create(&thread, null, &foo, null);
assert(status == 0);
foreach(i; 0..collectCount) {
serialize.lock_nothrow();
GC.collect();
serialize.unlock_nothrow();
}
pthread_join(thread, null);
}
writeln(`main done`);
}
//////////////////////////////////////////////////
Comment #5 by thomas.bockman — 2021-10-05T20:36:11Z
(In reply to thomas.bockman from comment #4)
> It appears to be a race condition between `thread_attachThis` and
> `GC.collect`. Serializing them prevents the crash:
Oops, I meant to submit that to bug 22358:
https://issues.dlang.org/show_bug.cgi?id=22358
Comment #6 by robert.schadek — 2024-12-07T13:37:49Z