我在OS X Lion上的pthread_specific()中崩溃，使用了在Mac OS X上用FPC和Indy 10编写的32位服务器应用程序。我很难找到原因。发生崩溃是因为无法读取gs:[tlsindex]，但我不知道为什么会发生这种情况。 tlsindex是正确的，因此描述符表必须以某种方式损坏。
有没有办法在OS X上使用gdb / Xcode 4打印描述符表？我在想，如果我知道内存中的地址，则可以在其上设置数据断点，并希望中断破坏描述符表的代码。不幸的是，我找不到有关如何在OS X(i386)上实际实现TLS的任何信息。
也许有人对如何解决这个问题有一个绝妙的主意？
最佳答案
如果这对其他人有用，我将回答我自己的问题。 OS X设置gs指向当前线程的TLS存储。这实际上是线程数据块(struct _pthread)的一部分，可以通过阅读Darwin源代码找到:
http://www.opensource.apple.com/source/Libc/Libc-391/pthreads/pthread_internals.h
检索指向该数据块的指针很容易:pthread_self将返回它。通过记录此内容，我发现线程仍在执行时，数据块最有可能被其他人释放了。通过使用mach_override捕获vm_deallocate，我发现这是由另一个线程的清理代码完成的。
最终，事实证明我在已经通过pthread_join分离的线程上调用pthread_detach。这两个函数都会释放线程存储空间。分离线程后(但在错误连接之前)，偶然创建了另一个线程，该线程具有完全相同的基址。联接将释放新线程，使其在没有数据块的情况下执行。与Windows相比，此错误是由pthread库的不同行为引起的，在Windows中，等待线程(联接)和关闭线程(分离)是两个完全不同的事情。
关于macos - 在Mac OS X上的pthread_specific()中崩溃，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15590865/