1

複数のスレッドでプロセスをデバッグしようとしていますが、スレッドの 1 つがNSRecursiveLockが使用可能になるのを待ってスタックしています - によって確認されましたGDB。ソースは に書かれていObjective Cます。

したがって、私が答えようとしている大きな問題は、これが発生したときに誰がロックを保持しているかということです。プロセス内の他のすべてのスレッドのコール スタックを調べましたが、手がかりは見つかりませんでした。

これはGDB、ロックの状態をダンプするときに表示されるものです。

(gdb) p \*(NSRecursiveLock\*)0x4c0cf30  $24 = {  `NSObject = {`  

    isa = 0xac94a3d0  
}  

    members of NSRecursiveLock:  
       _priv = 0x0  
}

ご覧のとおり、上記の出力はあまり有益ではありません。

ロックを保持している人を特定する方法

4

1 に答える 1

0

コードをスキャンして、NSRecursiveLock がロックされているすべての場所を見つけることができます。次に、gdbthread apply all btで、これらの場所のいくつかを検索します。
または、NSRecursiveLock のカスタム派生物を作成し、lock、unlock、tryLock、および lockBeforeDate メソッドを上書きして、スレッド ID を出力してからジョブを実行することもできます。

(void)lock
{
    NSLog(@"%@", [NSThread currentThread]);
    [super lock];
}

次に、プレーンな NSRecursiveLock の代わりにクラスを使用して、どのスレッドがロックを保持しているかを確認します。

于 2013-07-02T05:49:26.440 に答える