it-swarm.com.de

Werden "EXC_BREAKPOINT (SIGTRAP)" Ausnahmen durch das Debuggen von Haltepunkten verursacht?

Ich habe eine Multithread-App, die auf allen meinen Testmaschinen sehr stabil ist und für fast jeden meiner Benutzer stabil scheint (basierend auf keinen Abstürzen). Die App stürzt jedoch häufig für einen Benutzer ab, der so freundlich war, Absturzberichte zu senden. Alle Absturzberichte (~ 10 aufeinanderfolgende Berichte) sehen im Wesentlichen identisch aus:

Date/Time:       2010-04-06 11:44:56.106 -0700
OS Version:      Mac OS X 10.6.3 (10D573)
Report Version:  6

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread:  0  Dispatch queue: com.Apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.Apple.main-thread
0   com.Apple.CoreFoundation        0x90ab98d4 __CFBasicHashRehash + 3348
1   com.Apple.CoreFoundation        0x90adf610 CFBasicHashRemoveValue + 1264
2   com.Apple.CoreText              0x94e0069c TCFMutableSet::Intersect(__CFSet const*) const + 126
3   com.Apple.CoreText              0x94dfe465 TDescriptorSource::CopyMandatoryMatchableRequest(__CFDictionary const*, __CFSet const*) + 115
4   com.Apple.CoreText              0x94dfdda6 TDescriptorSource::CopyDescriptorsForRequest(__CFDictionary const*, __CFSet const*, long (*)(void const*, void const*, void*), void*, unsigned long) const + 40
5   com.Apple.CoreText              0x94e00377 TDescriptor::CreateMatchingDescriptors(__CFSet const*, unsigned long) const + 135
6   com.Apple.AppKit                0x961f5952 __NSFontFactoryWithName + 904
7   com.Apple.AppKit                0x961f54f0 +[NSFont fontWithName:size:] + 39

(.... mehr Text folgt)

Zuerst habe ich lange nach [NSFont fontWithName: size:] gesucht. Ich dachte mir, dass die Zeichensätze des Benutzers vielleicht irgendwie vermasselt wurden, sodass [NSFont fontWithName: size:] etwas Nicht-Vorhandenes anforderte und aus diesem Grund fehlschlug. Ich habe mit [[NSFontManager sharedFontManager] availableFontNamesWithTraits: NSItalicFontMask] eine Reihe von Code hinzugefügt, um die Verfügbarkeit von Schriftarten im Voraus zu überprüfen. Leider haben diese Änderungen das Problem nicht behoben.

Ich habe jetzt bemerkt, dass ich vergessen habe, einige Debugging-Haltepunkte zu entfernen, einschließlich _NSLockError, [NSException raise] und objc_exception_throw. Die App wurde jedoch definitiv mit "Release" als aktive Build-Konfiguration erstellt. Ich gehe davon aus, dass die "Release" -Konfiguration das Setzen von Haltepunkten verhindert. Ich bin jedoch auch nicht genau sicher, wie Haltepunkte funktionieren oder ob das Programm innerhalb von gdb ausgeführt werden muss, damit Haltepunkte wirksam werden.

Meine Fragen lauten: Kann ich die gesetzten Haltepunkte verlassen haben, könnte dies die Ursache für die vom Benutzer beobachteten Abstürze sein? Wenn ja, warum verursachen die Haltepunkte nur für diesen einen Benutzer ein Problem? Wenn nicht, hatte jemand anderes ähnliche Probleme mit [NSFont fontWithName: size:]?

Ich werde wahrscheinlich nur versuchen, die Haltepunkte zu entfernen und an den Benutzer zurückzusenden, aber ich bin mir nicht sicher, wie viel Geld ich noch bei diesem Benutzer hinterlassen habe. Und ich möchte allgemeiner verstehen, ob das Verlassen der festgelegten Haltepunkte möglicherweise ein Problem verursachen kann (wenn die App mit der Konfiguration "Release" erstellt wird).

73
Dennis

Werden "EXC_BREAKPOINT (SIGTRAP)" Ausnahmen durch das Debuggen von Haltepunkten verursacht?

Nein. Andersherum eigentlich: Ein SIGTRAP (Trace-Trap) bewirkt, dass der Debugger Ihr Programm unterbricht (unterbricht), genauso wie ein tatsächlicher Haltepunkt. Dies liegt jedoch daran, dass der Debugger bei einem Absturz immer bricht und ein SIGTRAP (wie mehrere andere Signale ) eine Art Absturz ist.

SIGTRAPs werden im Allgemeinen durch das Auslösen von NSExceptions verursacht, aber nicht immer - es ist sogar möglich, direkt eine Raise selbst zu erzeugen.

Ich habe jetzt bemerkt, dass ich vergessen habe, einige Debugging-Haltepunkte zu entfernen, einschließlich _NSLockError, [NSException raise] und objc_exception_throw.

Das sind keine Haltepunkte. Zwei davon sind Funktionen und -[NSException raise] ist eine Methode.

Meinten Sie, Sie setzen Haltepunkte auf diese Funktionen und diese Methode?

Ich gehe davon aus, dass die Verwendung der Konfiguration "Release" das Setzen von Haltepunkten verhindert.

Nein.

Die Konfigurationen sind build -Konfigurationen. Sie beeinflussen, wie Xcode Ihre Anwendungen erstellt.

Haltepunkte sind nicht Bestandteil des Builds. Sie legen sie im Debugger fest. Sie existieren nur, werden nur getroffen und stoppen Ihr Programm nur, wenn Sie Ihr Programm unter dem Debugger ausführen.

Da sie nicht Teil des Builds sind, ist es nicht möglich, Ihre Haltepunkte an einen Benutzer zu übergeben, indem Sie ihnen einfach das App-Paket geben.

Ich weiß nicht genau, wie Breakpoints funktionieren…

Wenn Ihr Programm den Haltepunkt erreicht, unterbricht (unterbricht) der Debugger Ihr Programm. Daraufhin können Sie den Status des Programms überprüfen und vorsichtig vorgehen, um zu sehen, wie das Programm fehlerhaft läuft.

Da der Debugger Ihr Programm stoppt, haben Haltepunkte keine Auswirkung, wenn Sie Ihr Programm nicht unter dem Debugger ausführen.

… Oder ob das Programm von gdb aus ausgeführt werden muss, damit die Haltepunkte Wirkung haben.

Es tut. Debugger-Haltepunkte funktionieren nur innerhalb des Debuggers.

Meine Fragen lauten: Kann ich die gesetzten Haltepunkte verlassen haben, könnte dies die Ursache für die vom Benutzer beobachteten Abstürze sein?

Nein.

Erstens, wie bereits erwähnt, sind Haltepunkte, selbst wenn diese Haltepunkte irgendwie auf das System des Benutzers übertragen wurden, nur im Debugger wirksam. Der Debugger kann nicht an einem Haltepunkt anhalten, wenn Ihr Programm nicht unter dem Debugger ausgeführt wird. Der Benutzer führt Ihre App fast sicher nicht unter dem Debugger aus, zumal sie ein Absturzprotokoll erhalten haben.

Selbst wenn Ihre App mit allen diesen Haltepunkten im Debugger ausgeführt wurde, wird ein Haltepunkt nur dann erreicht, wenn Ihr Programm diesen Punkt erreicht. Einer dieser Haltepunkte könnte nur ausgelöst werden, wenn Sie oder Cocoa _NSLockError, -[NSException raise] oder objc_exception_throw aufgerufen haben. Dies zu erreichen wäre nicht die Ursache des Problems, sondern ein Symptom des Problems.

Und wenn Sie aufgrund eines Aufrufs abstürzen, wird in Ihrem Absturzprotokoll mindestens einer von ihnen genannt. Tut es nicht.

Das hatte also nichts mit Ihren Haltepunkten zu tun (anderer Rechner, nicht mit dem Debugger), und es war keine Ausnahme von Cocoa. Wie ich bereits erwähnte, sind Cocoa-Ausnahmen eine Ursache für SIGTRAPs, aber sie sind nicht die einzige. Du hast einen anderen getroffen.

Wenn nicht, hatte jemand anderes ähnliche Probleme mit [NSFont fontWithName: size:]?

Wir können auf keinen Fall feststellen, ob irgendwelche Probleme ähnlich sind, weil Sie das Absturzprotokoll abschneiden. Wir wissen nichts über den Kontext, in dem der Absturz stattgefunden hat.

Das Einzige, was gut ausgeschnitten werden kann, ist der Abschnitt „Binäre Bilder“, da wir keine dSYM-Bundles haben. Dies bedeutet, dass wir diesen Abschnitt nicht verwenden können, um das Absturzprotokoll zu symbolisieren.

Sie dagegen können. Ich habe eine App für diesen Zweck geschrieben; Fügen Sie das Absturzprotokoll hinzu, und es sollte das dSYM-Bundle automatisch erkennen (Sie behalten das dSYM-Bundle für jeden Release-Build, den Sie verteilen, oder?), und stellen Sie Ihre Funktions- und Methodennamen im Stack-Trace wieder her, wo Ihre Funktionen und Methoden angezeigt werden.

Weitere Informationen finden Sie im Xcode Debugging Guide .

173
Peter Hosey

Es ist sehr wahrscheinlich, dass dieser Benutzer eine beschädigte Schriftart installiert hat. Der Stack-Trace unterstützt diese Hypothese definitiv, ebenso wie die Tatsache, dass nur ein Benutzer davon betroffen ist.

In diesem Fall können Sie nicht viel tun, außer den Benutzer dazu zu bringen, die anstößige Schriftart zu entfernen, da die Abstürze tief in Apples Code auftreten.

Bitten Sie den Benutzer, eine Schriftvalidierung in Font Book durchzuführen. Starten Sie dazu Font Book, klicken Sie in der Quellliste auf All Fonts und wählen Sie alle aufgelisteten Schriftarten aus. Sie können dann Validate Fonts im Menü File auswählen.

5
Rob Keniger

Haltepunkte werden nicht in die Binärdatei geschrieben. Die Chancen stehen gut, dass diese Person eine fehlerhafte Betriebssysteminstallation hat. Überprüfen Sie die Konsolenprotokolle auf Dyld-Nachrichten. 

0
Azeem.Butt

Ich hatte den gleichen Fehler. Aus einem unerklärlichen Grund war der Haltepunkt für das Auslösen der Ausnahme EXC_BREAKPOINT verantwortlich. Die Lösung bestand darin, den Haltepunkt zu entfernen, und der Code funktioniert dann.

EXC_BREAKPOINT ist ein Ausnahmetyp, den Debugger verwenden. Wenn Sie in Ihrem Code einen Haltepunkt festlegen, fügt der Compiler eine Ausnahme dieses Typs in den ausführbaren Code ein. Wenn die Ausführung diesen Punkt erreicht, wird die Ausnahme ausgelöst und vom Debugger abgefangen. Dann zeigt der Debugger Ihren Code in der Zeile "Haltepunkt" an. So arbeiten Debugger. In diesem Fall behandelt der Debugger die Ausnahme jedoch nicht richtig und wird als regulärer Ausnahmefehler angezeigt.

Ich habe diesen Fehler zweimal in meinem Leben gefunden:

  • vor etwa einem Jahr mit Xcode.
  • der andere verwendet Visual C++ vor etwa 15 Jahren.
0
veladan