SIGSEGV SEGV_ACCERR Raporty o awarii - co robić?

Question

Właśnie opublikowałem aplikację w AppStore z raportem o awariach Crittercism i otrzymałem sporo raportów o awariach związanych z błędem SIGSEGV. Crittercism daje mi StackTrace i kilka przydatnych szczegółów na temat statystyk użytkowania itp., Ale nadal jestem zdumiony tymi symbolizowanymi śladami stosu. Mam kilka pytań ogólnie o tego rodzaju rzeczy -

1. Wiele klas i metod w ślad stosu nie są używane nawet w mojej aplikacji (według mojej wiedzy), która mnie prowadzi uwierzyć, że te awarie są spowodowane prywatnymi interfejsami API firmy Apple. Rzuć okiem na ślad stosu u dołu tego pytania. Jak rozpoznać awarię mojej aplikacji, jeśli wszystkie metody i klasy zawarte w raporcie o awariach nie są bezpośrednio implementowane w moim kodzie?

2. Co oznaczają + znaki z numerami na końcu każdej linii w rozbitego wątku oznaczają?

3. Większość Q/A na StackOverflow że poprosić o awarii SIGSEGV powiedzieć, że są one spowodowane wyciekiem pamięci lub problemów, jednakjak mogę mieć awarię z powodu problemu pamięci, jeśli używam w ARC mój projekt iOS? Czy ARC nie powinna zarządzać wszystkimi tymi rzeczami?

4. Co należy zrobić, jeśli nie mogę zreplikować błędu/awarii?

5. Czy istnieje sposób, aby naprawdę przeczytać a StackTrace? CZY w ogóle jest coś, co byłoby pomocne w zrozumieniu tego, co się dzieje?

Oto StackTrace z głównym wątku Zawieszanie Raport z Crittercism że kwestia ta dotyczy:

Thread: Unknown Name (Crashed) 
0  UIKit         0x37307a22 -[UIView(CALayerDelegate) actionForLayer:forKey:] + 138 
1  QuartzCore       0x38fdfff7 -[CALayer actionForKey:] + 75 
2  QuartzCore       0x38fdffa7 _ZL12actionForKeyP7CALayerPN2CA11TransactionEP8NSString + 59 
3  QuartzCore       0x38fdfe93 _ZN2CA5Layer12begin_changeEPNS_11TransactionEjRP11objc_object + 131 
4  QuartzCore       0x38fdab87 _ZN2CA5Layer6setterEj12_CAValueTypePKv + 183 
5  QuartzCore       0x39007057 -[CALayer setBackgroundColor:] + 35 
6  UIKit         0x3731ef51 -[UIView(Internal) _setBackgroundCGColor:withSystemColorName:] + 1021 
7  APP NAME        0x000a301d 0x00086000 + 118813 
8  libdispatch.dylib      0x3962511f _dispatch_call_block_and_release + 11 
9  libdispatch.dylib      0x39628ecf _dispatch_queue_drain$VARIANT$mp + 143 
10 libdispatch.dylib      0x39628dc1 _dispatch_queue_invoke$VARIANT$mp + 41 
11 libdispatch.dylib      0x3962991d _dispatch_root_queue_drain + 185 
12 libdispatch.dylib      0x39629ac1 _dispatch_worker_thread2 + 85 
13 libsystem_c.dylib      0x3824da11 _pthread_wqthread + 361 

Answer 1

Trzeba symbolicate ten raport awarii. Numer 7 to linia, którą będziesz zainteresowany, ale nie ma informacji o symbolu, więc raport o awarii nie może być przetłumaczony na coś przydatnego dla ciebie. Aby symbolizować, potrzebujesz dokładnego kodu, który został użyty w wydaniu twojej aplikacji. Jeśli masz, wtedy można odwołać tę odpowiedź:

https://stackoverflow.com/a/13280585/1155387

Co do innych rzeczy:

1) Nie bądź taki szybki zakładać wewnętrzny błąd API. Twoja funkcja oczywiście zmienia kolor tła widoku, który wywołuje różne metody wewnętrznie. Prawdopodobnie jakoś minęło niepoprawna wartość. Nie bądź tak naiwny, aby myśleć, że kod, który piszesz, jest jedynym kodem, jaki kiedykolwiek został wykonany.

2) Znaki + oznaczają przesunięcie tego kodu wewnątrz obiektu binarnego. Nie przydatne dla ciebie.

3) Możesz łatwo mieć błąd pamięci z ARC, ponieważ ARC dotyczy tylko zakresu Objective-C. Wszelkie obiekty CoreFoundation itp. Nie będą zarządzane. Niekoniecznie to się dzieje, ale ARC nie oznacza, że ​​musisz przestać myśleć o pamięci razem.

4) Patrz wyżej

5) powyżej

Answer 2

byłbym skłonny być zrobiłeś coś takiego:

CALayer *layer = [CALayer layer]; 
layer.delegate = self; 

I wtedy Twój obiekt "ja", ale dealokowane przed ostatnie odwołanie do CALayer zostało odrzucone. Właściwość delegate nie ma wartości ref do obiektu ustawionego jako wartość layer.delegate. Nie ma to nic wspólnego z ARC (ARC nie naprawia w magiczny sposób wszystkich wskaźników używanych w twojej aplikacji).

Pierwszą rzeczą do zrobienia jest sprawdzenie kodu, w którym ustawiono delegata CALayer i upewnij się, że ten delegat powrócił do zera, gdy twój obiekt "self" zostanie zwolniony. To zerwie powiązanie CALayera z twoim obiektem. Generalnie powinieneś przesłać swój dsym do Crittercism, ale nie będzie to miało większego znaczenia w tym przypadku.