2012-11-30 2 views
8

Ho uno stack di console (non un rapporto di arresto anomalo) da un utente e sto cercando di determinare quale chiamata di metodo nella mia applicazione è stata l'ultima in piedi.Utilizzo di atos per determinare il nome del metodo in crash con dSYM

Conosco la versione dell'applicazione che stavano utilizzando e ho una copia di quella versione di debug/di rilascio, insieme al file dSYM per la copia archiviata.

Ma, quando provo a usare atos per sputare l'indirizzo di memoria, non sembra essere d'aiuto. (Sto usando 0x000000010e703bc0 dalla pila di seguito.)

craig-mbp:Desktop Craig$ atos -o MyApp.app_1.0.0.dSYM/Contents/Resources/DWARF/MyApp -arch x86_64 
0x000000010e703bc0 (<- entered by me) 
0x000000010e703bc0 (<- console output) 

Devo inserire un offset di qualche tipo? O qualche tipo di indirizzo di memoria matematico per determinare la posizione effettiva all'interno del blocco di memoria del mio programma, in base all'indirizzo fornito dall'utilizzatore?

Questa è la totalità della traccia dello stack che ho ricevuto:

28/11/12 10:48:56.220 AM MyApp[411] (
    0 CoreFoundation      0x00007fff8fee90a6 __exceptionPreprocess + 198 
    1 libobjc.A.dylib      0x00007fff8e94a3f0 objc_exception_throw + 43 
    2 CoreFoundation      0x00007fff8fee8e7c +[NSException raise:format:] + 204 
    3 Foundation       0x00007fff92b1ce5c -[NSPlaceholderString initWithString:] + 93 
    4 Foundation       0x00007fff92b1cde4 +[NSString stringWithString:] + 43 
    5 MyApp        0x000000010e703bc0 MyApp + 23488 
    6 MyApp        0x000000010e70a038 MyApp + 49208 
    7 MyApp        0x000000010e70b41a MyApp + 54298 
    8 MyApp        0x000000010e70bb92 MyApp + 56210 
    9 Foundation       0x00007fff92b22db5 __NSFireDelayedPerform + 358 
    10 CoreFoundation      0x00007fff8fea5da4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20 
    11 CoreFoundation      0x00007fff8fea58bd __CFRunLoopDoTimer + 557 
    12 CoreFoundation      0x00007fff8fe8b099 __CFRunLoopRun + 1513 
    13 CoreFoundation      0x00007fff8fe8a6b2 CFRunLoopRunSpecific + 290 
    14 HIToolbox       0x00007fff8b31c0a4 RunCurrentEventLoopInMode + 209 
    15 HIToolbox       0x00007fff8b31be42 ReceiveNextEventCommon + 356 
    16 HIToolbox       0x00007fff8b31bcd3 BlockUntilNextEventMatchingListInMode + 62 
    17 AppKit        0x00007fff948e7613 _DPSNextEvent + 685 
    18 AppKit        0x00007fff948e6ed2 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128 
    19 AppKit        0x00007fff948de283 -[NSApplication run] + 517 
    20 AppKit        0x00007fff94882cb6 NSApplicationMain + 869 
    21 MyApp        0x000000010e6ffab4 MyApp + 6836 

risposta

14

è in attesa di un indirizzo di carico. hai provato:

atos -o MyApp.app_1.0.0.dSYM/Contents/Resources/DWARF/MyApp -arch x86_64 -l 0x000000010E6FE000 

ottengo 0x000000010E6FE000 dal vostro esempio sottraendo 6836 (Base10) da 0x000000010e6ffab4 ... oppure si potrebbe utilizzare una qualsiasi delle altre voci di matematica mostrati lì per MiaApp.

Ecco un esempio di uno dei miei recenti arresti anomali, in cui il 0x2d000 era evidente dal registro degli arresti anomali. la prima riga è ciò che ho inserito sulla riga di comando. ogni altra riga dopo quella è l'uscita del programma (indentando artificialmente il mio input con $ o $> ... non c'è una tale richiesta sullo schermo).

$ atos -o /x/xcode/DerivedData/Xxxx/Build/Products/Debug-iphoneos/Xxxx.app.dSYM/Contents/Resources/DWARF/Xxxx -l 0x2d000 
got symbolicator for /x/xcode/DerivedData/Xxxx/Build/Products/Debug-iphoneos/Xxxx.app.dSYM/Contents/Resources/DWARF/Xxxx, base address 1000 
$> 0x0002f9a6 
0x000039a6 (in Xxxx) 
$> 0x0002f940 
0x00003940 (in Xxxx) 
$> 0x000c70f6 
-[TFHTTPOperation connection:didReceiveData:] (in Xxxx) + 754 
+0

Questo era perfetto: tutto ciò di cui avevo bisogno era convertire il '6836' in Base10 e sottrarlo dagli indirizzi di memoria. (Poi passa quel valore della diapositiva in "atos'.) Ora ho una traccia dello stack perfettamente simbolizzata, grazie mille. –