在Mac OS X上的pthread_specific（）中崩溃

Question

I'm getting a crash in pthread_specific() on OS X Lion using a 32-bit server application written with FPC and Indy 10 on Mac OS X. I'm finding it very hard to track down the cause. The crash occurs because gs:[tlsindex] is not readable, but I have no idea why this occurs. The tlsindex is correct, so the descriptor table must somehow have become corrupted.

Is there a way to print the descriptor table using gdb / Xcode 4 on OS X? I'm thinking that if I know the address in memory, I could set a data breakpoint on it and hopefully break at the code that corrupts the descriptor table. Unfortunately I can't find any information on how TLS is actually implemented on OS X (i386).

Or perhaps someone has a brilliant idea on how to tackle this problem?

Answer 1

I'll answer my own question in case this is ever useful for someone else. OS X sets up gs to point to the TLS storage for the current thread. This is actually a part of the thread's data block ( struct _pthread ), as can be found out by reading Darwin source code: http://www.opensource.apple.com/source/Libc/Libc-391/pthreads/pthread_internals.h

It's easy to retrieve a pointer to this data block: pthread_self will return it. By logging this, I found out that the data block was most likely freed by someone else while the thread is still executing. By trapping vm_deallocate using mach_override , I found out that this was done by the cleanup code for another thread.

Eventually it turned out that I was calling pthread_join on a thread that was already detached via pthread_detach . Both functions will free the thread storage. After the thread had been detached (but before the erroneous join), another thread was created with the exact same base address by chance. The join would free the new thread, leaving it to execute without its data block. This bug was caused by the different behavior of the pthread library compared to Windows, where waiting on a thread (join) and closing it (detach) are two completely different things.