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

Question

我在OS X Lion上的pthread_specific（）中崩潰，使用的是在Mac OS X上用FPC和Indy 10編寫的32位服務器應用程序。我很難找到原因。 發生崩潰是因為gs：[tlsindex]不可讀，但我不知道為什么會發生這種情況。 tlsindex是正確的，因此描述符表必須以某種方式損壞。

有沒有辦法在OS X上使用gdb / Xcode 4打印描述符表？ 我在想，如果我知道內存中的地址，則可以在其上設置數據斷點，並希望中斷破壞描述符表的代碼。 不幸的是，我找不到有關如何在OS X（i386）上實際實現TLS的任何信息。

也許有人對如何解決這個問題有一個絕妙的主意？

Answer 1

如果這對其他人有用，我將回答我自己的問題。 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中，等待線程（聯接）和關閉線程（分離）是兩個完全不同的事情。