¿Instrucciones de análisis spindump?

Generalmente:

• con un informe de bloqueo, obtienes un seguimiento de la pila
• con spindumps, obtiene múltiples seguimientos de pila durante un período de tiempo juntos.

Hay dos casos en los que es posible que desee examinar un spindump:

1. un ciclo infinito, probablemente llamando a la misma función una y otra vez
2. punto muerto.

El primer caso se puede ver desde el spindump por muchas llamadas a la misma función una y otra vez. Algo bueno para usar en tales situaciones es el Monitor de actividad: tome una muestra de un proceso colgado allí y podrá verlo de varias maneras útiles, ocultando marcos sin importancia, etc.

El segundo caso puede ser visto por diferentes subprocesos que esperan bloqueos al mismo tiempo.

Aquí hay un pequeño ejemplo:

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

Lo que esto me dice es que MyApp ha pasado por main, etc. y finalmente entró en una función CFRunLoopRunSpecific, entonces __CFRunLoopRun – desde allí (2557) llamó __CFRunLoopServiceMachPort, que llamó mach_msg y cayó en una trampa en mach_msg_trap (llamando a una llamada al sistema): cuando regresó, el seguimiento de la pila volvió a CFRunLoopRunSpecific, Donde __CFRunLoopRun fue llamado, que luego llama __CFRunLoopDoObservers, Y así sucesivamente.

Tenga en cuenta que esto no es un volcado de ningún proceso pendiente: puede probar de esta manera cualquier proceso en ejecución y ver qué funciones se llamaron durante esa muestra. Sin embargo, un ciclo infinito tendrá llamadas repetidas a alguna función una y otra vez; habrá el mismo árbol de llamadas una y otra vez. Por supuesto, esto puede significar un ciclo for simple, pero ahí es donde puede examinar, si el ciclo for no es por alguna razón infinito. Desafortunadamente, estos volcados giratorios suelen ser bastante largos, dependiendo de la función que esté llamando, por lo que puede llevar algún tiempo examinarlos.

El signo + al comienzo de la fila simplemente indica el comienzo de una línea; las líneas sin el signo + indican el comienzo de un nuevo hilo. Él ! y : los signos forman una línea, por lo que es más fácil para usted ver las llamadas posteriores, es decir, qué llamadas están en el mismo nivel. Además, | También se puede utilizar el carácter.

Los números indican cuánto tiempo pasó la aplicación en esa llamada en particular; están en la cantidad de muestras. El muestreo funciona porque la aplicación muestreada se suspende cada pocos milisegundos y se examina el marco de pila de cada subproceso. Si la aplicación todavía está en la misma función, la función obtiene +1.

Encontré esto al buscar 'spindump' en los recursos para desarrolladores de Mac. Nunca he visto uno, pero esta nota técnica a la que se hace referencia en la página del manual ReportCrash(8) parece mostrarle cómo leer los registros de fallas:

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

Y ReportCrash(8) se refirió a Spindump(8), mis disculpas. https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man8/ReportCrash.8.html

Pero aparentemente esto no te ayuda. Igual lo dejo aquí arriba.

Espero que esto ayude a alguien de alguna manera.