Rejestr awarii iTunesConnect jest częściowo symboliczny; nie wyświetla numerów wierszy

Question

Rejestr awarii w iTunesConnect dla mojej aplikacji XCode 3.2.5 - pokazuje nazwy metod, ale nie numery wierszy. Na przykład, w skróconego sprawozdania wypadku mam wklejony poniżej, pokazuje to:

0x000f5ef8 -[MyTableViewController dealloc] + 120

Są dwie rzeczy, które tutaj są zagadkowe mi, na którym będę wdzięczny pewien wgląd. Po pierwsze dlatego surowy plik .crash pochodzący z iTunesConnect jest już częściowo symbolizowany: pokazuje nazwę klasy i metody, ale nie plik kodu źródłowego i numer wiersza. Spodziewam się, że nieprzerwany dziennik błędów iTunesConnect będzie wyświetlał adresy w systemie szesnastkowym. Jak rozumiem, tylko raz pobieram dziennik awarii do mojego lokalnego systemu i jawnie wiążę go za pomocą odpowiedniego narzędzia (XCode Organizer, symbolicatecrash, atos, polecenie gdb x/i, itd.) Oraz dokładnych plików binarnych i dSYM aplikacji (posiadające pasujący identyfikator UUID), zobaczę pełne symbole klasy, metody, pliku kodu źródłowego i numeru linii. Nawet po pobraniu i wyświetleniu rejestru awarii w oknie systemu Windows wygląda na częściowo symbolizowany. Obawiam się, że mój binarny kod dystrybucyjny musi zawierać, w tym niektóre symbole debugowania, aby informacje te pojawiały się w nieprzetworzonym dzienniku awarii, mimo że "Projekt związany z taśmą" został ustawiony w ustawieniach docelowych Dystrybucja. Każdy wgląd tutaj byłby wielki.

Drugą rzeczą, która wprawia mnie w zakłopotanie i jest bardziej niepokojąca dla mnie w naprawianiu tego głośnego wypadku, jest ta sprawa offsetu. Bardzo starannie zlokalizowałem plik dSYM i plik binarny aplikacji z pasującym identyfikatorem UUID, umieściłem je w moim katalogu domowym, aby można było je znaleźć w Spotlight i wsp. I bez względu na to, co robię, nie mogę przekonwertować tego przesunięcia [MyTableViewController dealloc] + 120 do źródła plik kodu (który jest mi znany jako MyTableViewController.m) i numer linii. Próbowałem następujących sztuczek z nieprzetworzonym plikiem iTunesConnect .crash:

• Organizator XCode: jego "symbolikacja" nie wpływa na żadne zmiany w rejestrze awarii - jest taka sama.
• symbolicatecrash: To naprawdę nie narzeka na nic w trybie pełnym, a dziennik awarii wyjścia jest taki sam
• gdb: Używając tego samego ustawienia gdb i -arch, którego XCode 3.2.5 używa do tworzenia kompilacji dystrybucji, oraz ładowanie w pasujących binarnych symbolach aplikacji i symbolach dSYM na instrukcje this post, gdb 'x/i' i 'info line *' mówi mi, że [MyTableViewController dealloc] + 120 odpowiada całkowicie niezwiązanemu fragmentowi naszej bazy kodowej w zupełnie innym pliku - a .h, parzysty! Goniec dzikich gęsi.

Coś tu jest nie tak. Nawet pomimo zapewnienia dokładnie tego samego identyfikatora UUID w raporcie o awariach, pliku binarnym aplikacji i pliku dSYM ... żadne z tych narzędzi nie może przynieść faktycznego numeru linii, a wykonanie go na niskim poziomie wysyła mnie w dzikie gonitwy. Znajomość dokładnego numeru linii jest bardzo ważna, aby to naprawić, ponieważ nie jesteśmy w stanie odtworzyć tej awarii w domu, więc lecimy tutaj na ślepo. Wygląda na to, że jest to prosty nadmiernie zwolniony obiekt, ale nie jest jasne, który to dokładnie jest obiekt i nie jesteśmy w stanie odróżnić go od kontekstu. Zastanawiam się, czy istnieje niewłaściwe ustawienie kompilacji XCode, które w jakiś sposób przerywa proces symbolizacji.

Dziękujemy za poświęcony czas!

Poniżej przedstawiono skrócony nieprzetworzony dziennik .crash z iTunesConnect.

Incident Identifier: 09EAE058-7D55-4AE5-947A-17280FB0211A 
Hardware Model:  iPhone3,1 
Process:   MyApp [1895] 
Path:   /var/mobile/Applications/B4B872EF-CB0D-41D7-A7B5-435ADE479D0A/MyApp.app/MyApp 
Identifier:  MyApp 
Version:   ??? (???) 
Code Type:  ARM (Native) 
Parent Process: launchd [1] 

Date/Time:  2011-01-24 14:06:32.941 -0500 
OS Version:  iPhone OS 4.2.1 (8C148) 
Report Version: 104 

Exception Type: EXC_BAD_ACCESS (SIGSEGV) 
Exception Codes: KERN_INVALID_ADDRESS at 0xd0000000 
Crashed Thread: 0 

Thread 0 Crashed: 
0 libobjc.A.dylib     0x33479466 objc_msgSend + 18 
1 MyApp      0x000f5ef8 -[MyTableViewController dealloc] + 120 
2 CoreFoundation     0x33a26f74 -[NSObject(NSObject) release] 
3 libobjc.A.dylib     0x3347a812 objc_setProperty 
4 UIKit       0x320bb4a0 -[UINavigationController setDisappearingViewController:] 
5 UIKit       0x320bb478 -[UINavigationController _clearLastOperation] 
xx SNIP xx 
23 MyApp      0x00014eac main + 36 
24 MyApp      0x0000b324 start + 44 

XX SNIP xx 

Binary Images: 
    0x1000 - 0x1e3fff +MyApp armv7 <5570f8eee3bc11647732c12f96fe9553> /var/mobile/Applications/B4B872EF-CB0D-41D7-A7B5-435ADE479D0A/MyApp.app/MyApp 

Answer 1

Wystąpiły podobne problemy z wydaniem obiektu, który nie został zatrzymany lub który znajdował się w puli autorelease, a tym samym został dwukrotnie zwolniony.Najczęściej zdarza mi się awarię dla lokalizacji znajdującej się wewnątrz framework/iOS, ale wynika to z braku odpowiedniego zarządzania pamięcią. Nie mówię, że to się dzieje tutaj, ale po prostu jest to coś, czego doświadczyłem, gdy podobny błąd się pojawił.