Google breakpad generuje krótki stack trace na aplikacji iOS

0

Używam google-breakpad na aplikacji iOS, ale stack trace w pliku dmp jest na tyle krótki że nic z niego nie wynika.
W Xcode stack trace jest sporo dłuższy. Robię to w takich krokach:

  1. Wymuszam crash.
  2. dump_syms -a i386 -g NazwaAplikacji.app.dSYM NazwaAplikacji (mówię o tym pliku w Objects-normal/i386) > NazwaAplikacji\ i386.breakpad
  3. crash_report -S NazwaAplikacji\ i386.breakpad plikdmp > plikwynikowy.txt

To jest z Xcode:

Thread 0:

    #0	0x0209d952 in __pthread_kill ()
    #1	0x02061167 in pthread_kill ()
    #2	0x01dd09c9 in abort ()
    #3	0x01d9b53b in __assert_rtn ()
    #4	0x0000930a in CppCrashClass::crash() at    /Users/user/TestBreakpad/TestBreakpad/CppCrashClass.cpp:14
    #5	0x00002654 in -[ViewController makeCrash] at /Users/user/TestBreakpad/TestBreakpad/ViewController.mm:40
    #6	0x000025cd in -[ViewController crashTouchDown:] at /Users/user/TestBreakpad/TestBreakpad/ViewController.mm:35
    #7	0x015ee880 in -[NSObject performSelector:withObject:withObject:] ()

Thread 1:

    #0	0x0209e992 in kevent64 ()
    #1	0x01d23f36 in _dispatch_mgr_invoke ()
    #2	0x01d23c72 in _dispatch_mgr_thread ()

Thread 2:

    #0	0x0209e046 in __workq_kernreturn ()
    #1	0x02061dcf in _pthread_wqthread ()

a to breakpad:

Date: 1900-01-00 04:15:18 GMT
    Operating system: iOS (10.9.4 13E28)
    Architecture: x86
    Crash reason:  EXC_SOFTWARE / SIGABRT
    Crash address: 0x209d952
    
    Thread 0 (crashed)
     0 libsystem_kernel.dyl                     0x0209d952 __pthread_kill + 0xa
     1 libsystem_sim_c.dyli                     0x01dd09c8 abort + 0x7e
    
    Thread 1
     0 libsystem_kernel.dyl                     0x0209e992 kevent64 + 0xa
     1 libdispatch.dylib                        0x01d23c71 _dispatch_mgr_thread + 0x3b
     2 
    
    Thread 2
     0 libsystem_kernel.dyl                     0x0209e046 __workq_kernreturn + 0xa
     1 libsystem_pthread.dy                     0x02065ccd start_wqthread + 0x1d
    
    Thread 3
     0 libsystem_kernel.dyl                     0x02098f7a _mach_msg_trap + 0xa
     1 TestBreakpad                             0x00016d1c google_breakpad::ExceptionHandler::WaitForMessage(void*) + 0x47 (exception_handler.cc:487)
     2 
     3 libsystem_pthread.dy                     0x020605fa _pthread_body + 0x8f
     4 libsystem_pthread.dy                     0x02060484 _pthread_start + 0x81
     5 libsystem_pthread.dy                     0x02065cf1 thread_start + 0x21
    
    Thread 0:
       eip = 0x0209d952    esp = 0xbfffd87c    ebp = 0xbfffd898    ebx = 0x000356e6 
       esi = 0x00000006    edi = 0x020671a8    eax = 0x00000000    ecx = 0xbfffd87c 
       edx = 0x0209d952    efl = 0x00000286

Dlaczego thread 0 z breakpada jest taki krótki?

0

To wygląda tak, ten crash wynika z niezłapanego wyjątku.
Podczas debug-a XCode zatrzymuje ci w miejscu exception-a (tak działa assert), ale jak uruchomisz program normalnie to standardowy crash log będzie wyglądał tak:

// nagłowek ...

Application Specific Information:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Can't add self as subview'

Last Exception Backtrace:
0   CoreFoundation                      0x2ef9efd3 __exceptionPreprocess + 131
1   libobjc.A.dylib                     0x396e9ccf objc_exception_throw + 38
2   CoreFoundation                      0x2ef9ef15 +[NSException raise:format:] + 104
3   UIKit                               0x317c6555 -[UIView(Internal) _addSubview:positioned:relativeTo:] + 108
4   UIKit                               0x317c64df -[UIView(Hierarchy) addSubview:] + 30
5   UIKit                               0x3198f04f __53-[_UINavigationParallaxTransition animateTransition:]_block_invoke + 1402
6   UIKit                               0x317ccae5 +[UIView(Animation) performWithoutAnimation:] + 72
7   UIKit                               0x3198e899 -[_UINavigationParallaxTransition animateTransition:] + 728
8   UIKit                               0x3194bb47 -[UINavigationController _startCustomTransition:] + 2614
9   UIKit                               0x31868d83 -[UINavigationController _startDeferredTransitionIfNeeded:] + 418
10  UIKit                               0x31868b8d -[UINavigationController __viewWillLayoutSubviews] + 44
11  UIKit                               0x31868b25 -[UILayoutContainerView layoutSubviews] + 184
12  UIKit                               0x317bad79 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 380
13  QuartzCore                          0x3143862b -[CALayer layoutSublayers] + 142
14  QuartzCore                          0x31433e3b CA::Layer::layout_if_needed(CA::Transaction*) + 350
15  QuartzCore                          0x31433ccd CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 16
16  QuartzCore                          0x314336df CA::Context::commit_transaction(CA::Transaction*) + 230
17  QuartzCore                          0x314334ef CA::Transaction::commit() + 314
18  UIKit                               0x317be401 _UIApplicationHandleEventQueue + 8232
19  CoreFoundation                      0x2ef6a25b __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 14
20  CoreFoundation                      0x2ef6972b __CFRunLoopDoSources0 + 206
21  CoreFoundation                      0x2ef67f1f __CFRunLoopRun + 622
22  CoreFoundation                      0x2eed2f0f CFRunLoopRunSpecific + 522
23  CoreFoundation                      0x2eed2cf3 CFRunLoopRunInMode + 106
24  GraphicsServices                    0x33df4663 GSEventRunModal + 138
25  UIKit                               0x3181e16d UIApplicationMain + 1136
26  MyApplication             0x00079367 main (in MyApplication) (main.m:16)
27  MyApplication             0x00078810 start (in MyApplication) + 40

Thread 0 Crashed:
0   libsystem_kernel.dylib              0x39cac1f0 __pthread_kill + 8
1   libsystem_c.dylib                   0x39c5cfdd abort + 77
2   MyApplication             0x005b7397 uncaught_exception_handler (in MyApplication) + 27
3   CoreFoundation                      0x2ef9f2d7 __handleUncaughtException + 579
4   libobjc.A.dylib                     0x396e9f53 _objc_terminate() + 175
5   libc++abi.dylib                     0x38fa21c7 std::__terminate(void (*)()) + 79
6   libc++abi.dylib                     0x38fa1d2d __cxa_increment_exception_refcount + 1
7   libobjc.A.dylib                     0x396e9e17 objc_exception_rethrow + 43
8   CoreFoundation                      0x2eed2f85 CFRunLoopRunSpecific + 641
9   CoreFoundation                      0x2eed2cf3 CFRunLoopRunInMode + 106
10  GraphicsServices                    0x33df4663 GSEventRunModal + 138
11  UIKit                               0x3181e16d UIApplicationMain + 1136
12  MyApplication             0x00079367 main (in MyApplication) (main.m:16)
13  MyApplication             0x00078810 start (in MyApplication) + 40

Pytanie czy google-breakpad potrafi wyświetlić "Last Exception Backtrace"? Wygląda na to, że nie.

Swoją droga call stack w obu twoich crash logach wygląda dziwnie (jest za płytki nie widać main).

0

Main widać w tym z xcode, po prostu wkleiłem tylko 8 pierwszych pozycji. Martwi mnie jeszcze jedna rzecz
0x01dd09c9 in abort ()
0x01dd09c8 abort + 0x7e
I teraz właśnie nie wiem czy to coś breakpad na ios jest jakiś niedorobiony czy to ja coś źle robie.

0

Ok przetestowałem na iphonie i już nie ma tego problemu ze stack tracem, ale za to pojawił się problem z symbolizacją.
2014-09-09 15:29:17: stackwalker.cc:97: INFO: Couldn't load symbols for: TestBreakpad|A929209FA828349EB7CD40FF3BEBEDF80
Mam plik TestBreakpad armv7.breakpad i podaje ścieżkę do katalogu w którym się znajduje, ale nie może go załadować.

1

Symbole powinny być dostarczone dla konkretnego build-a, który musi być trzymany w pamięci w archiwum. Niestety, nie wystarczy, że jest to build z tej samej wersji kodu, musi to być dokładnie konkretny build.
Jeśli instalowałeś apkę przez uruchomienie z XCoda, to takiego crash loga nie da się zdekodować, bo ten build nie jest trawle trzymany.

Zrób paczkę ad hock i ją zainstaluj:

  1. Product/Archive
  2. przełącz się na widok Organizer-a
  3. w sekcji Archives wybierz właściwą wersję
  4. kliknij "Distribute…"
  5. wybierz "Save for Enterprise or Ad Hoc Deployment
  6. dalej jest oczywiste…
  7. … potem prawy przycisk myszy na wyeksportowanym archiwum i "Show in finder" byś mógł znaleźć plik z symbolami

Zainstaluj tą paczkę przez iTunsa na urzadzeni, wymuś crash-a, a potem powinieneś być w stanie zdekodować tego crash loga dla tej apki korzystając z symboli z wybranego archiwum.

Niestety wyszukiwanie archiwum dla danego crash loga jest dość skomplikowane. Identyfikator builda (UUID) w normalnym crash logu jest zaraz po ostatnim wątku. Coś takiego
0x4000 - 0x7effff +MyApplicatiom armv7 <e21f0368bd7930c7ba41b6124c151394> /private/var/mobile/Containers/Bundle/Application/2FE1F7C4-1EA1-4FAB-90BF-F19F84C214AC/MyApplicatiom.app/MyApplicatiom
w tym wypadku jest to e21f0368bd7930c7ba41b6124c151394.
By sprawdzić jaki jest UUID dla pliku z symbolami użyj takiej komendy:

xcrun dwarfdump --uuid <scieżka do pliku z symbolami>

Z samym Google breakpad, ci nie pomogę bo go nigdy nie używałem.

0

No dzięki ale już oganąłem, zrezygnowałem z crash_report na rzecz minidump_stackwalk, a potem to już wystarczyło symbole wrzucić do odpowiedniego folderu tak jak tu https://code.google.com/p/google-breakpad/wiki/LinuxStarterGuide#Producing_symbols_for_your_application i działa.

1 użytkowników online, w tym zalogowanych: 0, gości: 1