1

ブロック内で呼び出されたコードにメモリの問題があることを示すクラッシュ レポートを (優れたHockeydispatch_sync経由で) 受け取りました(または、少なくとも以下のクラッシュ レポート スニペットを解釈しています)。テストデバイスでこのクラッシュをまったく再現できませんでした（そのため、次のような戦略NSZombieEnabledは役に立ちません）。クラッシュ レポートをより有益なものにする (そして最終的には根本的な問題を解決する) ようにコードを変更できることをうれしく思いますが、どこから始めればよいかわかりません。何かご意見は？

Exception Type:  SIGSEGV
Exception Codes: SEGV_ACCERR at 0xb000000c
Crashed Thread:  7
...
Thread 7 Crashed:
0   libobjc.A.dylib            0x3979bb66 _objc_msgSend + 6
1   libdispatch.dylib          0x39c898fb _dispatch_barrier_sync_f_invoke + 27
2   App                        0x00260f23 __48-[Foo displayLinkCallback]_block_invoke + 147
3   libdispatch.dylib          0x39c85103 _dispatch_call_block_and_release + 11
4   libdispatch.dylib          0x39c894bf _dispatch_async_redirect_invoke + 111
5   libdispatch.dylib          0x39c8a7e5 _dispatch_root_queue_drain + 225
6   libdispatch.dylib          0x39c8a9d1 _dispatch_worker_thread2 + 57
7   libsystem_pthread.dylib    0x39db4dff __pthread_wqthread + 299

にdispatch_syncは静的シリアル キューが用意されています。_objc_msgSendブロック内の問題ではなく、このキューを参照する問題を示している可能性はありますか?

明白なことを先取りするために、これらのクラッシュ レポートにデッドロックの兆候は見られません。

更新 (2013 年 10 月 8 日)

要求に応じてコードを追加します (メソッドと変数の名前は変更されていますが、元に近いままです)。問題は のコピーのどこかにあると思われfooます。私の希望は、この質問がこのエラーをデバッグするための戦略を生み出すことでした。「行ごとにチェック」がブロック_objc_msgSend内のクラッシュをデバッグするための最良の戦略でdispatch_syncある場合、それは少し悲しいですが、この時点で得ることができるあらゆる助けを借ります.

また、私が調査しているクラッシュは、シングルコア デバイスで断続的にしか発生しないことを指摘しておく必要があります。

- (void) displayLinkCallback
{
    dispatch_async(_frameDispatchQueue, ^{
        if ([_lock tryLock])
        {
            dispatch_sync(_renderQueueSerial, ^{
                NSObject *fooCopy = nil;
                BOOL bar = NO;

                // prevents deallocation during subsequent copy
                // _foo is set and/or its child objects changed 
                // many times per second by other threads)
                NSObject *foo = _foo;

                // copy foo 
                fooCopy = [foo copy];

                bar = [self needsBarGivenFoo:fooCopy];
                if (bar)
                {
                    _lastFoo = foo;
                    [self goFoo:fooCopy];
                }
                else
                {
                    [self noFoo:fooCopy];
                }
            });
            [_lock unlock];
        }
    });
}
4

1 に答える 1

1

ソース ファイル内のこれらの参照について分析を開始することをお勧めします。この記号化されたクラッシュ ログは、クラッシュがクラスのdisplayLinkCallbackメソッドの何かに起因することを示唆しています。Fooおそらくそこから調査を開始する必要があります。

セグメンテーション違反があったことを示しています。しかし、そのメソッドのソース コードを見ずにさらに診断することは困難です。

于 2013-09-14T03:07:14.620 に答える