Używanie atos do określenia nazwy zderzenia z dSYM

Question

Mam stos konsoli (nie jest raportem awarii) od użytkownika i próbuję ustalić, która metoda wywołania w mojej aplikacji była ostatnią postacią stojącą.

Wiem, której wersji aplikacji używali, a ja mam kopię tej wersji wydania/debugowania wraz z plikiem dSYM dla zarchiwizowanej kopii.

Ale kiedy próbuję użyć atos, aby wypluć adres pamięci, nie wydaje się, aby pomóc. (Używam 0x000000010e703bc0 z poniższej stosie.)

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) 

Czy muszę wprowadzić przesunięcie jakiegoś? Albo jakąś matematykę adresową pamięci, aby określić faktyczną lokalizację w bloku pamięci mojego programu, na podstawie adresu podanego mi przez użytkownika?

To całokształt ślad stosu otrzymałem:

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 

Answer 1

to spodziewa się adres obciążenia. czy próbowałeś:

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

ja dostać 0x000000010E6FE000 od Twojego przykład poprzez odjęcie 6836 (Base10) z 0x000000010e6ffab4 ... czy można użyć dowolnego z pozostałych przedmiotów matematycznych przedstawionych tam MojaApl.

Oto przykład jednej z moich ostatnich awarii, gdzie 0x2d000 było widoczne w dzienniku awarii. pierwsza linia jest tym, co wpisałem w linii poleceń. każda kolejna linia to wynik programu (sztucznie wcinając moje wejście za pomocą $ lub $> ... nie ma takiej zachęty na ekranie).

$ 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