Les exceptions "EXC_BREAKPOINT (SIGTRAP)" sont-elles causées par des points d'arrêt de débogage ?

Question

J'ai une application multithread qui est très stable sur toutes mes machines de test et semble être stable pour presque tous mes utilisateurs (d'après l'absence de plaintes de plantage). L'application plante fréquemment pour un utilisateur, qui a eu la gentillesse d'envoyer des rapports de plantage. Tous les rapports de plantage (~10 rapports consécutifs) sont essentiellement identiques :

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

(....more text follows)

Tout d'abord, j'ai passé un long moment à étudier [NSFont fontWithName:size :]. Je me suis dit que les polices de l'utilisateur étaient peut-être mal fichues, de sorte que [NSFont fontWithName:size :] demandait quelque chose d'inexistant et échouait pour cette raison. J'ai ajouté un tas de code utilisant [[NSFontManager sharedFontManager] availableFontNamesWithTraits:NSItalicFontMask] pour vérifier la disponibilité des polices à l'avance. Malheureusement, ces modifications n'ont pas permis de résoudre le problème.

J'ai maintenant remarqué que j'ai oublié de supprimer certains points d'arrêt de débogage, notamment _NSLockError, [NSException raise] et objc_exception_throw. Cependant, l'application a bien été construite en utilisant "Release" comme configuration de construction active. Je suppose que l'utilisation de la configuration "Release" empêche la mise en place de tout point d'arrêt - mais là encore, je ne sais pas exactement comment fonctionnent les points d'arrêt ou si le programme doit être exécuté à partir de gdb pour que les points d'arrêt aient un quelconque effet.

Mes questions sont les suivantes : le fait que j'ai laissé les points d'arrêt définis pourrait-il être à l'origine des plantages observés par l'utilisateur ? Dans l'affirmative, pourquoi les points d'arrêt ne causeraient-ils un problème que pour cet utilisateur ? Sinon, quelqu'un d'autre a-t-il eu des problèmes similaires avec [NSFont fontWithName:size :]?

Je vais probablement essayer de supprimer les points d'arrêt et de les renvoyer à l'utilisateur, mais je ne sais pas combien de monnaie il me reste avec cet utilisateur. Et j'aimerais comprendre plus généralement si le fait de laisser les points d'arrêt définis peut éventuellement causer un problème (lorsque l'application est construite avec la configuration "Release").

Answer 1

Les exceptions "EXC_BREAKPOINT (SIGTRAP)" sont-elles causées par des points d'arrêt de débogage ?

Non. En fait, c'est l'inverse : Un SIGTRAP (trace trap) provoquera l'interruption de votre programme par le débogueur, de la même manière qu'un point d'arrêt réel le ferait. Mais c'est parce que le débogueur s'interrompt toujours lors d'un crash, et qu'un SIGTRAP (comme plusieurs autres SIGTRAP) peut interrompre votre programme. signaux ) est un type d'accident.

Les SIGTRAP sont généralement provoqués par la levée d'une exception NSE, mais pas toujours - il est même possible d'utiliser directement la fonction soulever un vous-même.

J'ai maintenant remarqué que j'ai oublié de supprimer certains points d'arrêt de débogage, notamment _NSLockError, [NSException raise] et objc_exception_throw.

Ce ne sont pas des points d'arrêt. Deux d'entre eux sont des fonctions et -[NSException raise] est une méthode.

Voulez-vous dire que vous avez mis des points d'arrêt sur ces fonctions et cette méthode ?

Je suppose que l'utilisation de la configuration "Release" empêche la mise en place de tout point d'arrêt

Non.

Les configurations sont les suivantes construire configurations. Elles affectent la façon dont Xcode construit vos applications.

Les points d'arrêt ne font pas partie de la compilation ; vous les définissez dans le débogueur. Ils n'existent, ne sont touchés et n'arrêtent votre programme que lorsque vous l'exécutez dans le débogueur.

Comme ils ne font pas partie de la compilation, il n'est pas possible de transmettre vos points d'arrêt à un utilisateur en lui donnant simplement le paquet d'applications.

Je ne sais pas exactement comment fonctionnent les points d'arrêt

Lorsque votre programme atteint le point d'arrêt, le débogueur interrompt votre programme, ce qui vous permet d'examiner l'état du programme et d'avancer prudemment pour voir comment le programme tourne mal.

Comme c'est le débogueur qui arrête votre programme, les points d'arrêt n'ont aucun effet lorsque vous n'exécutez pas votre programme sous le débogueur.

ou si le programme doit être exécuté à partir de gdb pour que les points d'arrêt aient un effet.

C'est le cas. Les points d'arrêt du débogueur ne fonctionnent que dans le débogueur.

Mes questions sont les suivantes : le fait que j'ai laissé les points d'arrêt définis pourrait-il être à l'origine des plantages observés par l'utilisateur ?

Non.

Tout d'abord, comme nous l'avons indiqué, même si ces points d'arrêt ont été transférés sur le système de l'utilisateur, les points d'arrêt ne sont efficaces que dans le débogueur. Le débogueur ne peut pas s'arrêter sur un point d'arrêt si votre programme n'est pas exécuté sous le débogueur. Il est presque certain que l'utilisateur n'exécute pas votre application sous le débogueur, d'autant plus qu'il en a tiré un journal d'incident.

Même s'ils ont exécuté votre application sous le débogueur avec tous ces points d'arrêt définis, un point d'arrêt n'est activé que lorsque votre programme atteint ce point, donc l'un de ces points d'arrêt ne pourrait être activé que si vous ou Cocoa appeliez _NSLockError , -[NSException raise] ou objc_exception_throw . Arriver à ce point ne serait pas la cause du problème, ce serait un symptôme du problème.

Et si vous vous êtes planté suite à l'appel de l'un d'entre eux, votre journal de bord devrait contenir au moins l'un d'entre eux. Ce n'est pas le cas.

Donc, ce n'était pas lié à vos points d'arrêt (machine différente, débogueur non impliqué), et ce n'était pas une exception Cocoa - comme je l'ai mentionné, les exceptions Cocoa sont une cause de SIGTRAPs, mais elles ne sont pas les seules. Vous en avez rencontré une autre.

Sinon, quelqu'un d'autre a-t-il rencontré des problèmes similaires avec [NSFont fontWithName:size :]?

Il n'y a aucun moyen de savoir si les problèmes que nous avons rencontrés sont similaires parce que vous avez coupé le journal du crash. Nous ne savons rien du contexte dans lequel le crash s'est produit.

La seule chose qu'il est bon de couper est la section "Images binaires", puisque nous n'avons pas vos bundles dSYM, ce qui signifie que nous ne pouvons pas utiliser cette section pour symboliser le journal de crash.

Vous, par contre, vous le pouvez. J'ai écrit une application à cette fin ; envoyez-lui le journal de bord, et il devrait détecter automatiquement le paquet dSYM (vous conservez le paquet dSYM pour chaque version que vous distribuez, n'est-ce pas ?) et restaurer les noms de vos fonctions et méthodes dans la trace de la pile partout où elles apparaissent.

Pour plus d'informations, voir le Guide de débogage Xcode .

Answer 2

Il est extrêmement probable que cet utilisateur a installé une police corrompue. La trace de la pile confirme cette hypothèse, tout comme le fait que le problème n'affecte qu'un seul utilisateur.

Il n'y a pas grand-chose à faire dans ce cas, si ce n'est demander à l'utilisateur de supprimer la police incriminée, car les plantages qui se produisent ont lieu en profondeur dans le code d'Apple.

Essayez de faire en sorte que l'utilisateur lance une validation de la police dans le Livre des polices. Pour ce faire, lancez le Livre des polices, cliquez sur Toutes les polices dans la liste des sources, puis sélectionnez toutes les polices répertoriées. Vous pouvez ensuite sélectionner Valider les polices de la Fichier menu.

Answer 3

J'ai rencontré ce problème lors du lancement d'une application iOS sur un appareil iOS 5 : l'application ne se liait pas de manière optionnelle à Social.framework (qui n'est disponible qu'à partir d'iOS 6).

Answer 4

Les points d'arrêt ne sont pas écrits dans le binaire. Il y a de fortes chances que cette personne ait une installation d'OS défectueuse. Vérifiez les journaux de la console pour les messages dyld.