On Tue, 20 Nov 2018, Josh Elsasser wrote: > The test suite for lang/sbcl has uncovered a race between pthread_join() > and the exiting thread: it may return before it's safe to unmap a custom > thread stack. > > In the exiting thread: > 1) pthread_exit() calls _thread_release() via the tc_thread_release > pointer. > 2) _thread_release() eventually calls _sem_post(&thread->donesem), > and then returns. > 3) pthread_exit() then calls __threxit(&tib->tib_tid). > > In the joining thread, _sem_wait(&thread->donesem, ...) then returns, > possibly before the exiting thread has reached __threxit().
and that's *perfectly* legal by the spec. The stack is relying on behavior above and beyond the POSIX spec. To quote XBD 2.9.8, "Use of Application-Managed Thread Stacks": The application grants to the implementation permanent ownership of and control over the application-managed stack when the attributes object in which the stack or stackaddr attribute has been set is used, either by presenting that attribute's object as the attr argument in a call to pthread_create() that completes successfully, or by storing a pointer to the attributes object in the sigev_notify_attributes member of a struct sigevent and passing that struct sigevent to a function accepting such argument that completes successfully. The application may thereafter utilize the memory within the stack only within the normal context of stack usage within or properly synchronized with a thread that has been scheduled by the implementation with stack pointer value(s) that are within the range of that stack. In particular, the region of memory cannot be freed, nor can it be later specified as the stack for another thread. Per that last sentence, the SBCL test program is invalid. Philip
