Sind “EXC_BREAKPOINT (SIGTRAP)” -Ausnahmen durch das Debugging von Breakpoints verursacht?

Ich habe eine Multithread-App, die auf allen meinen Testmaschinen sehr stabil ist und für fast jeden meiner Benutzer stabil zu sein scheint (basierend auf keinerlei Beschwerden über Abstürze). 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 fonts des Benutzers irgendwie vermasselt waren, so dass [NSFont fontWithName: size:] etwas nicht existierte und aus diesem Grund fehlte. Ich habe mit [[NSFontManager sharedFontManager] availableFontNamesWithTraits: NSItalicFontMask] eine Menge Code hinzugefügt, um im Voraus auf die Verfügbarkeit von Schriften zu prü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 Verwendung der “Release” -Konfiguration das Setzen von Breakpoints verhindert – aber ich bin mir nicht sicher, wie Breakpoints genau funktionieren oder ob das Programm innerhalb von gdb ausgeführt werden muss, damit Breakpoints wirksam werden.

Meine Fragen sind: Könnte ich die Bruchpunkte gesetzt haben, die Ursache für die vom Benutzer beobachteten Abstürze sind? Wenn ja, warum würden die Breakpoints nur für diesen einen Benutzer ein Problem verursachen? Wenn nicht, hat jemand anderes ähnliche Probleme mit [NSFont fontWithName: size:]?

Ich werde wahrscheinlich nur versuchen, die Breakpoints zu entfernen und zurück an den Benutzer zu senden, aber ich bin mir nicht sicher, wie viel Währung ich mit diesem Benutzer habe. Und ich würde gerne allgemeiner verstehen, ob das Verlassen der gesetzten Haltepunkte möglicherweise ein Problem verursachen könnte (wenn die App mit der “Release” -Konfiguration erstellt wird).

Sind “EXC_BREAKPOINT (SIGTRAP)” -Ausnahmen durch das Debugging von Breakpoints verursacht?

Nein. Andersherum, eigentlich: Ein SIGTRAP (Trace-Trap) wird den Debugger veranlassen, Ihr Programm zu unterbrechen (zu unterbrechen), genau wie ein tatsächlicher Breakpoint. Aber das liegt daran, dass der Debugger bei einem Absturz immer bricht und ein SIGTRAP (wie mehrere andere Signale ) eine Art von Absturz ist.

SIGTRAPs werden normalerweise durch NSExceptions ausgetriggers, aber nicht immer – es ist sogar möglich , einen selbst zu erstellen.

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 functionen und -[NSException raise] ist eine Methode.

Meinten Sie, Sie setzen Haltepunkte für diese functionen und diese Methode?

Ich nehme an, dass die Verwendung der “Release” -Konfiguration das Setzen von Breakpoints verhindert –

Nein.

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

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

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

Ich bin mir nicht sicher, wie genau Breakpoints funktionieren …

Wenn Ihr Programm den Haltepunkt erreicht, unterbricht (unterbricht) der Debugger Ihr Programm, woraufhin Sie den Zustand des Programms untersuchen und vorsichtig vorgehen können, um zu sehen, wie das Programm schief geht.

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

… oder ob das Programm innerhalb von gdb ausgeführt werden muss, damit Haltepunkte einen Effekt haben.

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

Meine Fragen sind: Könnte ich die Bruchpunkte gesetzt haben, die Ursache für die vom Benutzer beobachteten Abstürze sind?

Nein.

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

Selbst wenn sie Ihre App unter dem Debugger mit all diesen gesetzten Haltepunkten ausgeführt haben, wird ein Haltepunkt nur dann getroffen, wenn Ihr Programm diesen Punkt erreicht. _NSLockError kann einer dieser Haltepunkte nur _NSLockError , wenn Sie oder Cocoa _NSLockError , -[NSException raise] , oder objc_exception_throw . Zu diesem Zeitpunkt wäre nicht die Ursache des Problems, es wäre ein Symptom für das Problem.

Und wenn Sie aufgrund eines dieser Aufrufe abgestürzt sind, wird in Ihrem Crash-Log mindestens einer von ihnen genannt. Es tut es nicht.

Also, das war nicht mit Ihren Breakpoints verbunden (verschiedene Maschinen, Debugger nicht beteiligt), und es war keine Cocoa-Ausnahme – wie ich bereits erwähnte, sind Cocoa-Ausnahmen eine Ursache für SIGTRAPs, aber sie sind nicht die einzigen. Du bist einem anderen begegnet.

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

Wir können auf keinen Fall feststellen, ob die Probleme, die wir hatten, ähnlich sind, weil Sie das Absturzprotokoll abgeschnitten haben. Wir wissen nichts darüber, in welchem ​​Kontext der Absturz passiert ist.

Das einzige, was gut ausschneiden ist, ist der Abschnitt “Binärbilder”, da wir Ihre dSYM-Bundles nicht haben, was bedeutet, dass wir diesen Abschnitt nicht verwenden können, um das Absturzprotokoll zu symbolisieren.

Sie können andererseits. Ich habe zu diesem Zweck eine App geschrieben ; füttere das Crash-Log und es sollte das dSYM-Bundle automatisch erkennen (du behälst das dSYM-Bundle für jedes Release-Build, das du verteilst, oder?) und stelle deine functions- und Methodennamen überall dort wieder her, wo deine functionen und Methoden erscheinen.

Weitere Informationen finden Sie im Xcode-Debugging-Handbuch .

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 er nur einen Benutzer betrifft.

Es gibt nicht viel, was Sie in diesem Fall tun können, außer, dass der Benutzer die anstößige Schriftart entfernt, da die auftretenden Abstürze tief in Apples Code stattfinden.

Versuchen Sie, den Benutzer dazu zu bringen, eine Schriftartvalidierung in Font Book auszuführen. Starten Sie Font Book, klicken Sie auf Alle fonts in der Quellenliste, und wählen Sie dann alle aufgelisteten fonts aus. Sie können dann im Menü Datei die Option fonts prüfen auswählen.

Haltepunkte werden nicht in die Binärdatei geschrieben. Chancen sind gut, dass diese Person eine beschädigte Betriebssysteminstallation hat. Überprüfen Sie die Konsolenprotokolle auf dynamische Nachrichten.

Ich hatte den gleichen Fehler. Aus unerklärlichen Gründen war der Breakpoint dafür verantwortlich, die Ausnahme EXC_BREAKPOINT zu casting. Die Lösung bestand darin, den Haltepunkt zu entfernen, und dann funktioniert der Code.

EXC_BREAKPOINT ist eine Art von Ausnahme, die 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 ausgetriggers, und der Debugger fängt sie ab. Dann zeigt der Debugger Ihren Code in der “unterbrochenen” Zeile an. So arbeiten Debugger. In diesem Fall behandelt der Debugger die Ausnahme jedoch nicht korrekt und wird als regulärer Ausnahmeerrors angezeigt.

Ich habe diesen Fehler zwei Mal in meinem Leben gefunden:

  • eine mit Xcode vor etwa einem Jahr.
  • der andere nutzt Visual C ++ vor etwa 15 Jahren.