If I read the __reclaim_stacks code correctly, it frees the stack of all other threads after a fork. This is not a safe thing to do because pointers to on-stack data may have been written to global variables or shared with the current thread by other means, and those objects have to be remain valid after fork.
I don't think it is required to preserve objects on the stack of threads that have not been re-created in the child after fork(). POSIX states that only one thread will exist in the forked child. This seems equivalent to saying that all threads are duplicated in the child, but all child but the one that is the duplicate of the parent thread that called fork() are terminated before that remaining child thread continues execution. Given that objects on stacks of terminated threads are not required to be preserved either, I think this is not a bug. Please close this bug if you agree with this reasoning.
POSIX says: “If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space” This suggests to me that other thread stacks and TLS variables need to be preserved because they are part of the address space as well (at least if the addresses of these objects have been taken and published in some way to the current thread).
I think we need a clarification by the Austin Group.
Filed as: http://austingroupbugs.net/view.php?id=1114
POSIX thinks this is acceptable. We will have to see how this interacts with libraries that put references to thread-local data into global data structures. I suppose those would have to use an indirection, storing the shared data on the heap, and only a pointer to that in TLS.
C11 says this: “ The result of attempting to indirectly access an object with thread storage duration from a thread other than the one with which the object is associated is implementation-defined. ” So we can say that accessing TLS data after fork is undefined.