You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Detect an attempt to re-initialize the runtime thread object and abort immediately #112131
Can we detect an attempt to re-initialize the runtime thread object and abort immediately to make this issue easier to diagnose next time?
I can look into that. Need to check, but we may need to store the already-destructed info in pthread thread-specific data, as there were some reports that there may be issues with using thread_local vars on macOS after they have been destroyed.
On macOS, it looks like accessing a thread_local var from a pthread thread-specific data destructor leads to the thread_local var being reinitialized (data is zerored / constructor is called again, and the destructor is not called again), so storing info there about the Thread already being cleaned up would not detect the issue.
On Linux, in the same case accessing the thread_local var seemingly treats it as a new construction, but without running the constructor or zeroing the data, and the destructor is called a second time some time after the pthread thread-specific data destructor.
Based on the glibc docs it seems unsafe to use thread_local vars in pthread thread-specific data destructors. So, probably we would need to use pthread thread-specific data to store the info that the Thread has already been cleaned up.
Activity
dotnet-policy-service commentedon Feb 4, 2025
Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.
kouvel commentedon Mar 4, 2025
On macOS, it looks like accessing a
thread_localvar from a pthread thread-specific data destructor leads to thethread_localvar being reinitialized (data is zerored / constructor is called again, and the destructor is not called again), so storing info there about the Thread already being cleaned up would not detect the issue.On Linux, in the same case accessing the
thread_localvar seemingly treats it as a new construction, but without running the constructor or zeroing the data, and the destructor is called a second time some time after the pthread thread-specific data destructor.Based on the glibc docs it seems unsafe to use
thread_localvars in pthread thread-specific data destructors. So, probably we would need to use pthread thread-specific data to store the info that the Thread has already been cleaned up.Abort when there's an attempt to reinitialize a runtime thread object (…
Abort when there's an attempt to reinitialize a runtime thread object (…