我在OS X Lion中使用與FPC和印10在Mac OS X編寫的32位服務器應用程序獲得的pthread_specific（）崩潰，我非常發現它很難找到原因。發生崩潰是因爲gs：[tlsindex]不可讀，但我不知道爲什麼會發生這種情況。 tlsindex是正確的，所以描述符表必須以某種方式損壞。崩潰在Mac OS X pthread_specific（）
有沒有辦法用gdb/4的Xcode OS X上的打印描述符表？我在想，如果我知道內存中的地址，我可以在其上設置一個數據斷點，並希望在代碼中破壞描述符表。不幸的是我找不到有關TLS如何在OS X上實際實現的信息（i386）。
也許有人對如何解決這一問題的一個絕妙的主意？
我會回答我的問題的情況下，這是別人永遠有用。 OS X將gs設置爲指向當前線程的TLS存儲。這實際上是線程的數據塊（struct _pthread）的一部分，可以通過閱讀達爾文的源代碼中可以看出： http://www.opensource.apple.com/source/Libc/Libc-391/pthreads/pthread_internals.h
可以很容易地檢索指向該數據塊：pthread_self將返回它。通過記錄這一點，我發現數據塊在線程仍在執行時最有可能被其他人釋放。通過使用mach_override捕獲vm_deallocate，我發現這是通過另一個線程的清理代碼完成的。
最後事實證明，我打電話給pthread_join的線程已通過pthread_detach分離。這兩個函數都將釋放線程存儲。在線程被分離之後（但在錯誤加入之前），另一個線程被偶然地創建爲具有完全相同的基址。連接將釋放新線程，使其在沒有數據塊的情況下執行。這個錯誤是由pthread庫與Windows相比的不同行爲引起的，在這種情況下，等待線程（加入）並關閉它（分離）是兩個完全不同的事情。