Istruzioni di analisi spindump?

Question

Ho una collezione di spindumps focalizzata su un'app che deve essere analizzata, tuttavia non sono sicuro di come analizzare esattamente questi. Ho visto alcuni altri sviluppatori che sono in grado di analizzarli rapidamente mentalmente o con il software e tornare da me con i dettagli su dove stanno arrivando i blocchi e così via e spero di capire come analizzarli correttamente.

Dove si va ad analizzare correttamente spindumps?

Answer 1

generale:

• con un rapporto di incidente, si ottiene una traccia dello stack
• con spindumps, si ottiene più tracce dello stack per un periodo di tempo insieme.

ci sono due casi in cui si potrebbe desiderare di esaminare uno spindump:

1. un ciclo infinito, probabilmente chiamando la stessa funzione più e più
2. situazione di stallo.

Il primo caso può essere visto dallo spindump da molte chiamate alla stessa funzione più e più volte. Una buona cosa da usare in queste situazioni è Monitoraggio attività - prendere esempio di un processo sospeso e puoi visualizzarlo in diversi modi utili, nascondere cornici non importanti, ecc.

Il secondo caso può essere visualizzato da diversi thread in attesa su serrature allo stesso tempo

Ecco un piccolo esempio:

+ 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] 

Che cosa questo mi dice, è che MiaApp ha attraversato principale, ecc e finalmente in una funzione CFRunLoopRunSpecific, quindi __CFRunLoopRun - da lì (2557) si chiama , che ha chiamato mach_msg ed è entrato in una trappola allo mach_msg_trap (chiamando un syscall) - quando è tornato, lo stack trace è tornato a CFRunLoopRunSpecific, dove è stato chiamato __CFRunLoopRun, che quindi chiama __CFRunLoopDoObservers e così via.

Si noti che questo non è un controllo di processo in sospeso: è possibile campionare in questo modo qualsiasi processo in esecuzione e visualizzare quali funzioni sono state richiamate durante tale campione. Un ciclo infinito, tuttavia, avrà ripetute chiamate a una funzione più e più volte - ci sarà lo stesso albero delle chiamate più e più volte. Naturalmente, questo può significare un ciclo semplice, ma è lì che puoi esaminare, se il ciclo for non è per qualche motivo infinito.Sfortunatamente, questi dump di spin sono solitamente piuttosto lunghi, a seconda della funzione che si sta chiamando, quindi potrebbe richiedere del tempo per esaminare

Il segno + all'inizio della riga indica semplicemente l'inizio di una linea - linee senza il + segno indica un inizio di una nuova discussione. Il ! e: i segni creano una linea, quindi è più facile per te vedere le chiamate successive, ad esempio quelle che si trovano allo stesso livello. Inoltre, | il carattere può anche essere usato.

I numeri indicano per quanto tempo l'app è stata spesa in quella particolare chiamata - sono nel numero di campioni. Il campionamento funziona affinché l'app campionata venga sospesa ogni millisecondo e il frame dello stack venga esaminato per ogni thread. Se l'app è ancora nella stessa funzione, la funzione ottiene +1.

Answer 2

L'ho trovato durante la ricerca delle risorse degli sviluppatori Mac per "spindump". Non ho mai visto uno, ma questa nota tecnica di cui al ReportCrash (8) pagina di manuale sembra mostrare come leggere i log di crash:

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

E ReportCrash (8) di cui Spindump (8), Mie scuse. https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man8/ReportCrash.8.html

Ma a quanto pare questo non ti aiuta. Lascerò tutto qui altrettanto bene.

Spero che questo aiuti qualcuno in qualche modo.