16

分析する必要のあるアプリに焦点を当てたスピンダンプのコレクションがありますが、これらを分析する方法が正確にわかりません。これらを精神的またはソフトウェアですばやく解析し、ハングが発生する場所などの詳細を私に返すことができる他の開発者を見てきました。これらを適切に分析する方法を理解したいと思っています。

スピンダンプを適切に分析するにはどこに行きますか？

4

2 に答える 2

21

一般的：

  • クラッシュレポートを使用すると、スタックトレースを取得できます
  • スピンダンプを使用すると、一定期間にわたって一緒に複数のスタックトレースを取得できます。

スピンダンプを調べたい場合は2つあります。

  1. 無限ループ、おそらく同じ関数を何度も呼び出す
  2. デッドロック。

最初のケースは、同じ関数を何度も呼び出すことでスピンダンプから確認できます。このような状況で使用するのに適したのは、Activity Monitorです。そこでハングしたプロセスのサンプルを取得すると、重要でないフレームを非表示にするなど、いくつかの便利な方法でそれを表示できます。

2番目のケースは、同時にロックを待機しているさまざまなスレッドで表示できます。

ここに小さな例があります：

+ 2663 start  (in MyApp) + 52  [0x100001bb4]
+   2663 main  (in MyApp) + 39  [0x100001be7]  main.m:65
+     2663 NSApplicationMain  (in AppKit) + 869  [0x7fff8ea27cb6]
+       2663 -[NSApplication run]  (in AppKit) + 517  [0x7fff8ea83283]
+         2663 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]  (in AppKit) + 128  [0x7fff8ea8bed2]
+           2663 _DPSNextEvent  (in AppKit) + 685  [0x7fff8ea8c613]
+             2663 BlockUntilNextEventMatchingListInMode  (in HIToolbox) + 62  [0x7fff8dd53cd3]
+               2663 ReceiveNextEventCommon  (in HIToolbox) + 356  [0x7fff8dd53e42]
+                 2663 RunCurrentEventLoopInMode  (in HIToolbox) + 209  [0x7fff8dd540a4]
+                   2663 CFRunLoopRunSpecific  (in CoreFoundation) + 290  [0x7fff95dec6b2]
+                     2557 __CFRunLoopRun  (in CoreFoundation) + 1078  [0x7fff95decee6]
+                     ! 2556 __CFRunLoopServiceMachPort  (in CoreFoundation) + 195  [0x7fff95de7803]
+                     ! : 2556 mach_msg  (in libsystem_kernel.dylib) + 70  [0x7fff93630c42]
+                     ! :   2556 mach_msg_trap  (in libsystem_kernel.dylib) + 10  [0x7fff93631686]
+                     ! 1 __CFRunLoopServiceMachPort  (in CoreFoundation) + 199  [0x7fff95de7807]
+                     97 __CFRunLoopRun  (in CoreFoundation) + 728  [0x7fff95decd88]
+                     ! 97 __CFRunLoopDoObservers  (in CoreFoundation) + 369  [0x7fff95e11921]
+                     !   97 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__  (in CoreFoundation) + 23  [0x7fff95e119b7]
+                     !     97 __83-[NSWindow _postWindowNeedsDisplayOrLayoutOrUpdateConstraintsUnlessPostingDisabled]_block_invoke_01208  (in AppKit) + 46  [0x7fff8f05a971]
+                     !       90 _handleWindowNeedsDisplayOrLayoutOrUpdateConstraints  (in AppKit) + 738  [0x7fff8ea8f2ac]
+                     !       : 89 -[NSView displayIfNeeded]  (in AppKit) + 1830  [0x7fff8ea8fd73]

これが私に伝えているのは、MyAppがメインなどを通過し、最終的に関数に入ったということですCFRunLoopRunSpecific。そして__CFRunLoopRun、そこから（2557）と呼ばれ__CFRunLoopServiceMachPort、（syscallを呼び出して）mach_msgでトラップになりました。 mach_msg_trap、スタックトレースはに戻りCFRunLoopRunSpecific、ここで__CFRunLoopRunが呼び出され、次に、が呼び出さ__CFRunLoopDoObserversれます。

これはハングしているプロセスのスピンダンプではないことに注意してください。この方法で実行中のプロセスをサンプリングし、そのサンプル中に呼び出された関数を表示できます。ただし、無限ループでは、ある関数への呼び出しが何度も繰り返されます。同じ呼び出しツリーが何度も繰り返されます。もちろん、これは単純なforサイクルを意味する場合がありますが、forサイクルが何らかの理由で無限ではない場合は、ここで調べることができます。残念ながら、これらのスピンダンプは、呼び出している関数によっては通常非常に長いため、調査に時間がかかる場合があります。

行の先頭にある+記号は、単に行の始まりを示します。+記号のない行は、新しいスレッドの始まりを示します。！！および：記号が線を引くので、後続の呼び出し、つまり同じレベルの呼び出しを簡単に確認できます。さらに、| 文字も使用できます。

数字は、アプリがその特定の呼び出しに費やした時間を意味します-それらはサンプルの数に含まれています。サンプリングは、サンプリングされたアプリが数ミリ秒ごとに中断され、各スレッドのスタックフレームが検査されるように機能します。アプリがまだ同じ関数内にある場合、関数は+1を取得します。

于 2012-11-20T22:27:59.653 に答える
0

これは、Mac開発者向けリソースで「spindump」を検索したときに見つかりました。一度も見たことがありませんが、ReportCrash（8）のマニュアルページで参照されているこのTechNoteは、クラッシュログの読み取り方法を示しているようです。

https://developer.apple.com/library/mac/#technotes/tn2004/tn2123.html

そして、ReportCrash（8）はSpindump（8）を参照しました。お詫びします。 https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man8/ReportCrash.8.html

しかし、どうやらこれはあなたを助けません。ここにも残しておきます。

これが誰かを何らかの形で助けてくれることを願っています。

于 2012-11-16T09:36:06.217 に答える