更新 #3: これに関する元の github の問題へのリンクと、現在試している解決策の可能性があります... AFNetworking 1.3.0 に更新しています
https://github.com/AFNetworking/AFNetworking/issues/1054
更新 #2: このデッドロック状態になると、[AFHTTPClient HTTPRequestOperationWithRequest:success:failure:] メソッドで死にかけている可能性があります。NSLogs をペッパーし、問題のあるユーザーに送信して、何が表示されるかを確認しました。
更新 #1: これは、それが起こったときの最近のスピン レポートです - これはいくつかの興味深いことを指しているようです - 誰かこれについて何か考えがありますか?
https://dl.dropboxusercontent.com/u/2053112/myapp_AFNetworking.spin
コードが非常に近いため、github.com/AFNetworking/AFNetworking/issues/907 への参照を追加します。
また、ウォッチドッグ ブロックは (失敗しようとしている) 操作を検出してキャンセルすることができましたが、残念ながら、キャンセルされたとしても、損傷は既に発生しており、アプリはデッドロックすることにも注意してください。
元の投稿:
他の誰かがそのようなものを見たことがあるかどうかを確認するために、次のような状況があります。
ファイル システム イベントを列挙して使用し、処理してサーバーにアップロードするファイルのディレクトリを監視する UIElement (メニューバー項目のみ) MacOSX アプリケーションで AFNetworking を使用しています。ファイルはコア データ ストアに保存され、アップロードが必要などのマークが付けられます。
GCDを使用すると、ラウンドロビンで実行される3つのネットワーク操作があります.それぞれが次のプロセスをトリガーし、最後のプロセスが再びプロセスをトリガーします.一度に処理されるのは1つだけです. 各操作の間に 1 ～ 2 秒の遅延があります。これらの操作の 1 つが POST で、ファイルをアップロードする必要があるかどうかを確認します。次は、必要に応じてファイルを PUT します。最後の DELETE は、削除対象としてマークされたすべてのファイルを削除します。PUT は私の問題です。
PUT を処理する (クラス) メソッドは、新しく作成されたディスパッチ キューで呼び出され、次の方法で明示的に使用されます。
dispatch_queue_t q_put = dispatch_queue_create("com.myapp.put", NULL);
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, NSEC_PER_SEC * kPause), q_put, ^(void){
@autoreleasepool {
PUTfiles(completionBlock);
}
});
dispatch_release(q_put);
次に、このメソッドは NSOperationQueue と NSBlockOperation を作成し、それをキューに追加して解放します。NSBlockOperation は、すべての作業がある場所です。基本的に、このブロックは Core Data からファイル URL を取得し、(AFNetworking を介して) PUT を作成し、アップロードのためにキューに入れます。詳細には、ファイルが添付された PUT として NSURLRequest を作成しています。次に、AFHTTPRequestOperation が作成され、enqueueHTTPRequestOperation がそれをキューに入れます。
この時点まで、すべてが良好です。プロセスは実際にはほとんどの場合問題なく実行されます。NSURLRequest がタイムアウトしたときに問題が発生します。60 秒後、NSURLRequest がタイムアウトした場合、AFNetworking は AFHTTPRequestOperation の失敗ブロックを呼び出そうとしますが、代わりにアプリの「ビーチ ボール」を呼び出します。アプリ内の他のファイル プロセスは引き続き実行されますが、AFNetworking はデッドロックされます。おそらくある種のセマフォを待機しています。コール スタックの例を次に示します。
Thread 0x958 DispatchQueue 1 priority 47
31 ??? (My App + 4980) [0x106b5b374]
31 NSApplicationMain + 869 (AppKit) [0x7fff8630fc06]
31 -[NSApplication run] + 517 (AppKit) [0x7fff8636b1d3]
31 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128 (AppKit) [0x7fff86373e22]
31 _DPSNextEvent + 685 (AppKit) [0x7fff86374563]
31 BlockUntilNextEventMatchingListInMode + 62 (HIToolbox) [0x7fff90109ae3]
31 ReceiveNextEventCommon + 356 (HIToolbox) [0x7fff90109c52]
31 RunCurrentEventLoopInMode + 209 (HIToolbox) [0x7fff90109eb4]
31 CFRunLoopRunSpecific + 290 (CoreFoundation) [0x7fff8de710e2]
31 __CFRunLoopRun + 789 (CoreFoundation) [0x7fff8de717f5]
31 __CFRunLoopDoSources0 + 245 (CoreFoundation) [0x7fff8de4e455]
31 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 (CoreFoundation) [0x7fff8de4eb31]
31 _cfstream_shared_signalEventSync + 640 (CoreFoundation) [0x7fff8ded3e00]
31 _signalEventSync + 108 (CoreFoundation) [0x7fff8de9503c]
31 ??? (My App + 162305) [0x106b81a01]
31 CFWriteStreamWrite + 380 (CoreFoundation) [0x7fff8de6f56c]
31 boundPairWrite + 586 (CoreFoundation) [0x7fff8df3f7ea]
31 _CFStreamSignalEvent + 615 (CoreFoundation) [0x7fff8de94df7]
31 _cfstream_solo_signalEventSync + 100 (CoreFoundation) [0x7fff8de94fc4]
31 _signalEventSync + 108 (CoreFoundation) [0x7fff8de9503c]
31 ??? (My App + 162305) [0x106b81a01]
31 CFWriteStreamWrite + 380 (CoreFoundation) [0x7fff8de6f56c]
31 boundPairWrite + 149 (CoreFoundation) [0x7fff8df3f635]
31 __psynch_mutexwait + 10 (libsystem_kernel.dylib) [0x7fff8a758122]
*31 psynch_mtxcontinue + 0 (mach_kernel) [0xffffff80005b34e0]
注: これは、Mountain Lion を実行している一部のマシンでのみ発生します。ユーザーの 5% が報告されていますが、特定の 1 台のマシンでのみ完全に再現およびテストできました。言うまでもなく、問題が自然に現れるまでに何時間もかかることがあります.
注: 通常、ユーザーがアプリのメニューバー NSStatusItem にカーソルを合わせると、回転するビーチ ボールとして表示されます。
特定のフォールバック キュー (成功と失敗の両方) を渡しても、同じ問題が発生するように見えますが、(少なくとも 1 つの) マシンでのみ発生することに注意してください。他のマシンはまったく問題なく動作します。これは、フォールバック キューで成功ブロックを呼び出しているときに実際にクラッシュした最近のクラッシュです。これが発生したときは 8 時間以上実行されており、これまでに成功ブロックを何百回も正常に呼び出していました。
Crashed Thread: 10 Dispatch queue: com.myapp.put.success.queue
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000008
VM Regions Near 0x8:
Thread 10 Crashed:: Dispatch queue: com.myapp.put.success.queue
0 libdispatch.dylib 0x00007fff89920e1c _dispatch_retain + 0
1 libdispatch.dylib 0x00007fff89923871 dispatch_source_cancel + 17
2 com.mydomain.myapp 0x0000000109154722 __PUTfiles_block_invoke281 + 98
3 com.mydomain.myapp 0x000000010916b32c __64-[AFJSONRequestOperation setCompletionBlockWithSuccess:failure:]_block_invoke79 + 44
4 libdispatch.dylib 0x00007fff89923f01 _dispatch_call_block_and_release + 15
5 libdispatch.dylib 0x00007fff899200b6 _dispatch_client_callout + 8
6 libdispatch.dylib 0x00007fff8992147f _dispatch_queue_drain + 235
7 libdispatch.dylib 0x00007fff899212f1 _dispatch_queue_invoke + 52
8 libdispatch.dylib 0x00007fff899211c3 _dispatch_worker_thread2 + 249
9 libsystem_c.dylib 0x00007fff8705cd0b _pthread_wqthread + 404
10 libsystem_c.dylib 0x00007fff870471d1 start_wqthread + 13
Thread 10 crashed with X86 Thread State (64-bit):
rax: 0x1c711b723ffeb051 rbx: 0x0000000000000000 rcx: 0x00007faa010eb040 rdx: 0x00000000a1a1a1a1
rdi: 0x0000000000000000 rsi: 0x00007faa010eb000 rbp: 0x000000010aa5ad20 rsp: 0x000000010aa5ad08
r8: 0x00007faa0287b970 r9: 0x0000000064cb29bf r10: 0x00007faa0289a570 r11: 0x000000006744ce88
r12: 0x0000000000010001 r13: 0x0000000000000000 r14: 0x00007faa01842540 r15: 0x00007faa01842574
rip: 0x00007fff89920e1c rfl: 0x0000000000010206 cr2: 0x0000000000000008
Logical CPU: 0
アプリを終了して再起動すると、リセットに役立ちます。これは、NSURLRequest がタイムアウト (60 秒) した場合にのみ発生することに注意してください。サーバーが実際に応答するその他の障害は正常に処理され、ハングは発生しません。プロセスは続行され、適切に再試行されます。
現在、PUT の開始から 45 秒後に呼び出され、まだ完了していない場合は操作をキャンセルするウォッチドッグ ブロックを試しています。これを 0.25 秒に設定すると、問題のマシンで問題なく動作します - 操作をキャンセルし、再試行します。これで問題が解決することを願っていますが、このユーザーのマシンでさまざまなことを試して2週間このバグと戦ってきました（追跡するためにログステートメントを使用してビルドを重ねました）息を止めていません. 上記の成功ブロックを呼び出すときにもクラッシュしたので、それが正しいアプローチであることを少し心配しています-成功クラッシュは今朝だけでした-以前は常に失敗クラッシュでした.
考え？前もって感謝します！