iPhone Absturz stack-trace VS Crash-Bericht
Nur einige Zeit... auf einen Absturz, ohne es zu verstehen. Das ist ein Klassiker:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000010Das führt mich zu einem Speicher-Problem, die auf die ungültige Adresse 0x10
Was mich stört ist, dass mir die crash-Bericht und stack-trace, der sich unterscheiden:
Die crash-Bericht, gesendet durch den Benutzer (symbolicated erfolgreich, dass das passiert) :
Thread 0 Crashed:
0 libobjc.A.dylib 0x000027d8 objc_msgSend + 16
1 UIKit 0x0005e9d2 -[UIViewAnimationState animationDidStop:finished:] + 54
2 QuartzCore 0x0002d8c2 run_animation_callbacks(double, void*) + 286
3 QuartzCore 0x0002d764 CA::timer_callback(__CFRunLoopTimer*, void*) + 116
4 CoreFoundation 0x000567f4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 8
5 CoreFoundation 0x000562a6 __CFRunLoopDoTimer + 854
6 CoreFoundation 0x0002779e __CFRunLoopRun + 1082
7 CoreFoundation 0x00027270 CFRunLoopRunSpecific + 224
8 CoreFoundation 0x00027178 CFRunLoopRunInMode + 52
9 GraphicsServices 0x000045ec GSEventRunModal + 108
10 GraphicsServices 0x00004698 GSEventRun + 56
11 UIKit 0x0000411c -[UIApplication _run] + 396
12 UIKit 0x00002128 UIApplicationMain + 664
13 MyApp 0x00003158 main (main.m:13)
14 MyApp 0x00003120 0x1000 + 8480Der crash-stack-trace (heute live von einem Exception-Handler)
0 MyApp 0x000d79c3 0x0 + 883139
1 MyApp 0x000d790b 0x0 + 882955
2 libSystem.B.dylib 0x302765d3 _sigtramp + 42
3 UIKit 0x31eab9d9 -[UIViewAnimationState animationDidStop:finished:] + 60
4 QuartzCore 0x33a178c9 _ZL23run_animation_callbacksdPv + 292
5 QuartzCore 0x33a1776b _ZN2CAL14timer_callbackEP16__CFRunLoopTimerPv + 122
6 CoreFoundation 0x3084e7fb __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 14
7 CoreFoundation 0x3084e2ad __CFRunLoopDoTimer + 860
8 CoreFoundation 0x3081f7a5 __CFRunLoopRun + 1088
9 CoreFoundation 0x3081f277 CFRunLoopRunSpecific + 230
10 CoreFoundation 0x3081f17f CFRunLoopRunInMode + 58
11 GraphicsServices 0x31e445f3 GSEventRunModal + 114
12 GraphicsServices 0x31e4469f GSEventRun + 62
13 UIKit 0x31e51123 -[UIApplication _run] + 402
14 UIKit 0x31e4f12f UIApplicationMain + 670
15 MyApp 0x0000315f 0x0 + 12639
16 MyApp 0x00003128 0x0 + 12584Beide unterscheiden sich, und die stack-trace-Punkte, um den Absturz in meinem code, aber Adressen kann ich weder symbolicate noch identifizieren. Ich denke die crash-Bericht gibt an, dass eine Nachricht gesendet wurde, auf eine freigegebene Instanz... Wahrscheinlich im Zusammenhang mit der Nutzung von :
+ (void)setAnimationDelegate:(id)delegate
+ (void)setAnimationDidStopSelector:(SEL)selectorAlso hier (endlich!) meine Fragen:
- Was erklärt die Unterschiede zwischen den logs? (libobjc.Ein vs-libSystem.B ??)
- Hat der SIGBUS stammt aus meinem code oder von UIKit?
- Wie kann ich entziffern, der stack-trace der oberen Adressen (0x000d79??, die atos nicht behoben)
- Ist, dass das, was ich denke, ein Problem mit einer animation scheitern zu Ende? ähnlich wie diese > Wie unset Delegierten auf UIView setAnimationDelegate: anrufen?
- AFAIK setAnimationDelegate soll beibehalten delegieren... Jemand bestätigen?
BEARBEITEN: ich kann nicht mit NSZombiesEnabled ist dies ein crash-Bericht aus einem veröffentlichten app einen Absturz, dass ich es nicht geschafft zu reproduzieren Entwicklungsumgebung. Ich habe nur diese Protokolle, um zu diagnostizieren.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Wenn ich sehe, objc_msgSend an der Spitze, der mein Vertrauen von den restlichen stack ist geringer, als der Fehler, der gibt diese neigt dazu, schlechte Dinge tun, um den Stapel.
GuardMalloc ist gut für diese, da der Versuch, etwas mit den freigegeben Speicherplatz, stürzt die app ab sofort im debugger. Der Stapel intakt sein. (Das macht die app sehr langsam, aber es ist ein sehr mächtiges Werkzeug.)
Den beiden stapeln sind die gleichen bis auf die UIViewAnimationState Methode aufrufen. Die version, die kam aus Ihrer exception-handler zeigt C++ entstellte statt der regulären Namen angezeigt, in der crash-log.
(Wie ich es verstehe) _sigtramp ist die Methode des Aufrufs von signal-handler und ist die Abkürzung für Signal-Trampolin. Der stack-Einträge darüber hinaus sind wahrscheinlich die signal-handler-code.
Beantwortung meiner eigenen Frage -, Wochen-bis später, denn ich hatte keine relevante Antworten, die meisten sind nur Vermutungen, ich wünschte, ich hätte präziser Antworten, aber ich denke, meine Frage war unklar :
Hoffe, dass jemand hilft.
Sollten Sie versuchen, NSZombie, um Informationen zu bekommen über das, was Objekt, das Sie veröffentlicht haben. Dies ist ein sehr nützliches tool, wenn man EXC_BAD_ACCESS.
Aktivieren NSZombie Folgendes tun:
Name: NSZombieEnabled
Wert: JA
Dann führen Sie Ihre app wie gewohnt und wenn es abstürzt, es sollte Ihnen sagen, welche freigegeben-Objekt die Nachricht empfangen hat.
1. Ich bin mir nicht 100% sicher, aber ich denke, die Diskrepanz ist darauf zurückzuführen, wie die Anwendung ausgeführt wird. In der zweiten melden, es sieht aus wie Sie die App über XCode in den debug-Modus, eine sigtramp signal wurde gesendet, um anzuzeigen, EXC_BAD_ACCESS error.
2. Ihr code - den Fehler kann aus dem UIKit Bibliothek, aber es ist ein Ergebnis eines Problems mit Ihrem Gebrauch.
3. Dies ist, wo NSZombieEnabled wird Ihr Leben viel einfacher! Wenn Sie Ihre Anwendung ausführen, mit der NSZombieEnabled flag XCode halten "zombie" - Objekte statt der Objekte freigegeben. Wenn ein zombie-Objekt wird eine Nachricht gesendet, die dem Prozess, den Fehler abfangen und lassen Sie Sie wissen genau, was für ein Objekt wurde die Nachricht gesendet.
Wenn Sie mit XCode 4 aktivieren NSZombieEnabled mithilfe der folgenden Anweisungen,...
Wie richte ich NSZombieEnabled in Xcode 4?
Für ältere Versionen befolgen Sie diese Anweisungen,...
http://www.cocoadev.com/index.pl?NSZombieEnabled
4. Es ist in der Tat angezeigt, dass Ihre animation Delegierten wurde freigegeben, bevor die animation abgeschlossen.