Break on EXC_BAD_ACCESS in XCode?
https://stackoverflow.com/questions/1622079
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Ich bin neu auf iPhone Entwicklung und XCode im Allgemeinen und habe keine Ahnung, wie ein EXC_BAD_ACCESS Signal beginnen Fehlerbehebung. Wie kann ich XCode bekommen genau an der Linie zu brechen, die den Fehler verursacht?
Ich kann nicht scheinen XCode zu bekommen auf der Linie zu stoppen das Problem verursacht, aber ich habe die folgenden Zeilen in meiner Debug-Konsole sehen:
Sun 25. Oktober 15.12.14 jasonsmacbook Testproject [1289]: CGContextSetStrokeColorWithColor: ungültiger Kontext
Sun 25. Oktober 15.12.14 jasonsmacbook Testproject [1289]: CGContextSetLineWidth: ungültiger Kontext
Sun 25. Oktober 15.12.14 jasonsmacbook Testproject [1289]: CGContextAddPath: ungültiger Kontext
Sun 25. Oktober 15.12.14 jasonsmacbook Testproject [1289]: CGContextDrawPath: ungültiger Kontext
2009-10-25 15: 12: 14,680 LanderTest [1289: 207] *** - [CFArray objectAtIndex:]: Nachricht gesendet deallokierten Instanz 0x3c4e610
Nun, ich bin versucht, auf den Kontext zu zeichnen ich von UIGraphicsGetCurrentContext() abrufen und auf das Objekt übergeben, die ich mit zeichnen möchten.
Weitere Trial and Error Debugging und ich fand, dass ein NSMutableArray ich eine Eigenschaft haben, für meine Klasse war ein Zombie. Ich ging in die init Funktion für die Klasse und hier ist der Code, den ich wurde mit:
if ((self = [super init])) {
NSMutableArray *array = [NSMutableArray array];
self.terrainBlocks = array;
[array release];
}
return self;
}
entfernte ich die [array release] Linie und es nicht mehr gibt mir das EXC_BAD_ACCESS Signal, aber ich bin jetzt verwirrt darüber, warum das funktioniert. Ich dachte, dass, wenn ich die Eigenschaft verwendet, es behielt er automatisch für mich, und so sollte ich loslassen von innen init so, dass ich nicht ein Leck haben. Ich bin gründlich verwirrt darüber, wie das funktioniert und alle Führer und Stackoverflow Fragen, die ich gelesen habe mich nur verwirren mehr darüber, wie in meinem init-Methode setzen Eigenschaften. Es scheint kein Konsens zu sein, wie auf dem Weg der beste ist.
Lösung
Für alle EXC_BAD_ACCESS Fehler, versuchen Sie in der Regel eine Nachricht an ein freigegebenes Objekt zu senden. Der BEST Weg, um diese nach unten zu verfolgen, ist verwenden NSZombieEnabled .
Dies funktioniert, indem nie ein Objekt tatsächlich die Freigabe, sondern indem man es als „Zombie“ Verpackung und einen Flag im Inneren Einstellung, die es normalerweise sagt würde freigelassen worden. Auf diese Weise, wenn Sie es versuchen wieder zugreifen zu können, wissen, dass es nach wie vor, was es war, bevor Sie den Fehler gemacht, und mit diesem wenig Informationen, können Sie in der Regel denselben Weg zurückverfolgen, um zu sehen, was das Problem war.
Es hilft vor allem im Hintergrund-Threads, wenn manchmal der Debugger auf alle notwendigen Informationen scheißt aus.
sehr wichtig beachten ist jedoch, dass Sie zu 100% müssen sicherstellen, dass diese nur in Ihrem Debug-Code und nicht Ihren Verteilungscode. Denn nichts ist jemals veröffentlicht, wird Ihre App auslaufen und auslaufen und undicht werden. Erinnern mich, dies zu tun, habe ich dieses Protokoll in meinem AppDelegate:
if(getenv("NSZombieEnabled") || getenv("NSAutoreleaseFreedObjectCheckEnabled"))
NSLog(@"NSZombieEnabled/NSAutoreleaseFreedObjectCheckEnabled enabled!");
Wenn Sie Hilfe benötigen, die genaue Linie zu finden, erstellen einen Build-and-Debug ( CMD-Y ) anstelle eines Errichten-and-Run ( CMD-R ). Wenn die App abstürzt, wird der Debugger Ihnen genau zeigen, welche Zeile und in Kombination mit NSZombieEnabled, sollten Sie in der Lage, genau herauszufinden, warum.
Andere Tipps
Über Ihr Array. Die Zeile
NSMutableArray *array = [NSMutableArray array];
nicht wirklich gibt Ihnen ein beibehaltene Objekt, sondern ein Objekt Autorelease. Es wird wahrscheinlich in der nächsten Zeile beibehalten, aber dann sollten Sie lösen es nicht in der dritten Zeile. Siehe dieser
Dies ist die Grundregel:
Sie nehmen Besitz eines Objekts, wenn Sie es mit einem Methodennamen mit „alloc“ oder „neu“ oder enthält „Kopie“ (zum Beispiel alloc, newObject oder mutableCopy) beginnt, das erstellen, oder wenn Sie es senden behalten Nachricht. Sie sind für den Verzicht auf das Eigentum an Objekten verantwortlich Sie Release oder Autorelease eigene benutzen. Zu jeder anderen Zeit ein Objekt zu erhalten, müssen Sie nicht loslassen.
In Xcode 4 können Sie Zombies durch Klicken auf dem Schema Dropdown (oben links, rechts neben der Stopp-Taste) aktivieren -> Schema bearbeiten -> Diagnose Tab -> Aktivieren Zombie Objekte
Xcode / GDB immer auf EXC_BAD_ACCESS bricht, müssen Sie nur den Call-Stack Ihren Weg nach oben arbeiten, um den Code zu finden, die es ausgelöst hat.
, dass diese Arten von Fehlern oft mit autoreleased Objekten auftreten, was bedeutet, dass die eigentliche Ursache des Problems nicht in dem Call-Stack wird die EXC_BAD_ACCESS ausgelöst. Das ist, wenn NSZombieEnabled und NSAutoreleaseFreedObjectCheckEnabled nützlich werden.
Eine neue Antwort auf einen alten Thread ... in XCode 4 der effektivste Weg EXC_BAD_ACCESS Ausnahmen zu diagnostizieren ist Instrumente zu benutzen, um Ihre App zum Profil (von XCode Klick Produkt / Profil und wählen Zombies). Dies wird helfen, Sie Nachrichten an deallokierten Objekte gesendet zu identifizieren.
Von den Stanford CS193P Klassen: Wenn Sie einen Haltepunkt (manuell, durch Haltepunkte bearbeiten) fügen Sie für die symbolobjc_exception_throw können Sie ein viel besseres Bild davon bekommen, was schief gelaufen ist - lassen die Dinge auf den Punkt gehen, wo der Debugger stoppt von selbst dazu neigt, obskure Dinge und schrauben Sie den Stack-Trace auf. Wenn Sie halt in objc_exception_throw kann man oft genau zurückblicken, was den Zugang / Betrieb Ihr Problem verursacht hat.
Ein weiterer hilfreicher Ansatz Haltepunkte, die direkt auslösen, nachdem die Ausnahme auftritt:
Öffnen Sie das Fenster Haltepunkte (Run - Show - Breakpoints) und fügen Sie zwei symbolische Stützpunkte genannt „objc_exception_throw“ und „[NSException raise]“
Von: http://blog.emmerinc.be/index.php/2009/03/19/break-on-exception-in-xcode/
Ich wollte nur für die andere hinzuzufügen, die von einem Web kommen, nach Lösungen für die gleichen Fehler gesucht, aber mit unterschiedlichen Fehlern. In meinem Fall habe ich den gleichen Fehler, wenn ich versuchte NSDictionary mit Tippfehlern in Schlüsselnamen zu instanziiert wo ich hinzufügen vergessen „@“ vor meinem Schlüssel:
NSDictionary *dic = [NSDictionary dictionaryWithObjectsAndKeys: myObj1, @"goodKey", myObj2, "badkey @ is missing in front", nil];
Ich hoffe, ich habe nicht eine identische Antwort verpassen, aber ich habe festgestellt, dass es möglich ist, für einige Projekte, diesen Fehler zu werfen auf Grunde auf Simulatoren für ältere iOS-Versionen ausgeführt wird, der mit einer Projektabhängigkeit oder Rahmen nicht kompatibel. Ich war zu lange einen von diesem nach unten zu jagen, bevor es zu merken war gerade in den -older- Simulator Versionen geschieht, wie iPhone 4S wurde die App nicht einmal sollte versuchen, zu unterstützen.
wäre schön gewesen, eine ausführlichere Fehlermeldung bekommen zu haben, aber ich könnte mir vorstellen, dass die Verantwortung des Rahmens ist, wo es ... Jedenfalls entstanden ist, ist dies eine ziemlich häufige Such Landung und vielleicht wird dies jemand helfen vermasseln bis so schlecht wie ich mich befinden.
Vor der Aktivierung der Zombies empfehle ich zunächst alle Warnungen loszuwerden (wenn Sie welche haben). Einfache Dinge wie eine nicht leer Funktion ohne returncan Ursache dieser Fehler. Wenn Sie nicht über Warnungen gehen Sie wie die anderen Antworten vorschlagen.
