Mac OSXでFPCとIndy10を使用して作成された32ビットサーバーアプリケーションを使用して、OS X Lionでpthread_specific（）がクラッシュします。原因を突き止めるのが非常に難しいと感じています。gs：[tlsindex]が読み取れないためにクラッシュが発生しますが、なぜこれが発生するのかわかりません。tlsindexは正しいので、記述子テーブルが何らかの理由で破損している必要があります。
OSXでgdb/Xcode 4を使用して記述子テーブルを印刷する方法はありますか？メモリ内のアドレスがわかっていれば、それにデータブレークポイントを設定して、記述子テーブルを破損するコードでブレークできると思います。残念ながら、TLSが実際にOS X（i386）にどのように実装されているかについての情報は見つかりません。
それとも、誰かがこの問題に取り組む方法について素晴らしいアイデアを持っていますか？
これが他の誰かに役立つ場合に備えて、私は自分の質問に答えます。gsOS Xは、現在のスレッドのTLSストレージを指すように設定します。これは実際にはスレッドのデータブロック（struct _pthread）の一部であり、Darwinのソースコードを読むとわかります：
http ：//www.opensource.apple.com/source/Libc/Libc-391/pthreads/pthread_internals.h
このデータブロックへのポインタを取得するのは簡単です：pthread_selfそれを返します。これをログに記録することで、スレッドの実行中にデータブロックが他の誰かによって解放された可能性が高いことがわかりました。mach_overridevm_deallocateを使用してトラップすることにより、これが別のスレッドのクリーンアップコードによって行われたことがわかりました。
pthread_join最終的に、を介してすでに切り離されているスレッドを呼び出していたことが判明しましたpthread_detach。どちらの関数もスレッドストレージを解放します。スレッドが切り離された後（ただし、誤った結合の前）、偶然にまったく同じベースアドレスで別のスレッドが作成されました。結合により、新しいスレッドが解放され、データブロックなしで実行されたままになります。このバグは、Windowsと比較してpthreadライブラリの動作が異なることが原因で発生しました。この場合、スレッドの待機（結合）とスレッドのクローズ（デタッチ）はまったく異なるものです。