Les exceptions "EXC BREAKPOINT (SIGTRAP)" sont-elles causées par le débogage des points d'arrêt?
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 (basé sur aucune plainte de plantages). L'application se bloque fréquemment pour un utilisateur, cependant, qui a eu la gentillesse d'envoyer des rapports de plantage. Tous les rapports de plantage (~10 rapports consécutifs) semblent 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
(....plus de texte suit)
Tout d'abord, j'ai passé beaucoup de temps à enquêter sur [NSFont fontWithName:size:]. J'ai pensé que peut-être de l'utilisateur les polices ont été foiré en quelque sorte, de sorte que [NSFont fontWithName: size:] demandait quelque chose d'inexistant et échouait pour cette raison. J'ai ajouté un tas de code en utilisant [[NSFontManager sharedFontManager] availableFontNamesWithTraits:NSItalicFontMask] pour vérifier la disponibilité de la police à l'avance. Malheureusement, ces changements n'ont pas résolu le problème.
J'ai maintenant remarqué que j'ai oublié de supprimer certains points d'arrêt de débogage, y compris _NSLockError, [NSException raise] et objc_exception_throw. Cependant, l'application a été définitivement construite en utilisant "Release" comme configuration de construction active. Je suppose que l'utilisation de la configuration" Release " empêche la définition de tous les points d'arrêt-mais là encore, Je ne suis pas sûr 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 effet.
Mes questions sont: Est-ce que le fait d'avoir quitté les points d'arrêt définis pourrait être la cause des plantages observés par l'utilisateur? Si oui, pourquoi les points d'arrêt ne causeraient-ils un problème que pour cela un 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 renvoyer à l'utilisateur, mais je ne suis pas sûr de la monnaie qu'il me reste avec cet utilisateur. Et je voudrais comprendre plus généralement si laisser les points d'arrêt définis pourrait éventuellement causer un problème (lorsque l'application est construite en utilisant la configuration "Release").
4 réponses
Les exceptions "EXC_BREAKPOINT (SIGTRAP)" sont-elles causées par des points d'arrêt de débogage?
Non. Inversement, en fait: un SIGTRAP (trappe de trace) provoquera la rupture (interruption) de votre programme par le débogueur, de la même manière qu'un point d'arrêt réel. Mais c'est parce que le débogueur se casse toujours sur un plantage, et un SIGTRAP (comme plusieurs autres signaux) est un type de plantage.
Les SIGTRAPs sont généralement causés par des NSExceptions lancées, mais pas toujours-c'est même possible de directement soulever un vous-même.
J'ai maintenant remarqué que j'ai oublié de supprimer certains points d'arrêt de débogage, y compris _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 définissez des points d'arrêt sur ces fonctions et cette méthode?
Je suppose que l'utilisation de la configuration "Release" empêche le réglage de tout points d'arrêt--
Non.
Les configurations sont construire configurations. Ils affectent la façon dont Xcode construit vos applications.
Les points D'arrêt ne font pas partie de la construction; vous les définissez dans le débogueur. Ils n'existent que, ne sont touchés et n'arrêtent votre programme que lorsque vous exécutez votre programme sous le débogueur.
Comme ils ne font pas partie de la construction, il n'est pas possible de transmettre vos points d'arrêt à un utilisateur simplement en leur donnant l'ensemble d'applications.
Je le suis 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 (interrompt) votre programme, après quoi vous pouvez examiner l'état du programme et avancer soigneusement pour voir comment le programme va mal.
Puisque 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 effet.
C'est vrai. Les points d'arrêt du débogueur ne fonctionnent que dans le débogueur.
Mes questions sont: Est-ce que le fait d'avoir quitté les points d'arrêt définis pourrait être la cause des plantages observés par l'utilisateur?
Non.
Tout d'abord, comme indiqué, même si ces points d'arrêt ont été reporté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 ne s'exécute pas sous le débogueur. L'utilisateur presque certainement ne fonctionne pas votre application sous le débogueur, d'autant plus qu'ils ont obtenu un crash log hors de celui-ci.
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 atteint que lorsque votre programme atteint ce point, donc l'un de ces points d'arrêt ne peut se déclencher que si vous ou Cocoa avez appelé _NSLockError, -[NSException raise], ou objc_exception_throw. Arriver à ce point ne serait pas la cause du problème, c'est qu'un symptôme du problème.
Et si vous avez crash à la suite de l'un des ceux qui sont appelés, votre journal de plantage aurait au moins un d'entre eux nommé dans celui-ci. Ce n'est pas le cas.
Donc, cela 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é un autre.
Sinon, quelqu'un d'autre a-t-il eu des problèmes similaires avec [NSFont fontWithName:size:]?
Impossible de savoir si tous les problèmes que nous avons eu sont similaires parce que vous avez coupé le journal des accidents. Nous ne savons rien du contexte dans lequel l'accident s'est produit.
La seule chose qui est bonne à découper est la section "images binaires", puisque nous n'avons pas vos paquets dSYM, ce qui signifie que nous ne pouvons pas utiliser cette section pour symboliser le journal de plantage.
Vous, en revanche, pouvez. J'ai écrit une application à cet effet; alimentez le journal de crash, et il devrait détecter le paquet dSYM automatiquement (vous gardez le DSYM bundle pour chaque version que vous distribuez, n'est-ce pas?) et restaurez vos noms de fonction et de méthode dans la trace de la pile partout où vos fonctions et méthodes apparaissent.
Pour plus d'informations, consultez le Guide de débogage Xcode.
Il est extrêmement probable que cet utilisateur ait installé une police corrompue. La trace de la pile soutient définitivement cette hypothèse, tout comme le fait qu'elle n'affecte qu'un seul utilisateur.
Il n'y a pas grand-chose que vous pouvez faire dans ce cas, sauf demander à l'utilisateur de supprimer la police incriminée, car les plantages qui se produisent ont lieu au fond du code D'Apple.
Essayez d'amener l'utilisateur à exécuter une validation de police dans le Livre de polices. Pour ce faire, lancez Police Book, cliquez sur Toutes les polices dans la liste source et ensuite, sélectionnez toutes les polices répertoriées. Vous pouvez ensuite sélectionner valider les policesdans le menu Fichier.
Les points D'arrêt ne sont pas écrits dans le binaire. Les chances sont bonnes que cette personne a une installation de système d'exploitation cassé. Vérifiez les journaux de la console pour les messages dyld.
J'ai eu le même message d'erreur. Pour une raison inexplicable, le point d'arrêt était responsable du lancement de l'exception EXC_BREAKPOINT. La solution était de supprimer le point d'arrêt, puis le code fonctionne.
EXC_BREAKPOINT est un type d'exception utilisé par les débogueurs. Lorsque vous définissez un point d'arrêt dans votre code, le compilateur insère une exception de ce type dans le code exécutable. Lors de l'exécution atteint ce point, l'exception est levée, et le débogueur l'attrape. Puis le débogueur affiche votre code dans la ligne "point de rupture". C'est de cette façon débogueurs de travail. Mais dans ce cas, le débogueur ne gère pas l'exception correctement et est présenté comme une erreur d'exception.
J'ai trouvé cette erreur deux fois dans ma vie:
- un en utilisant Xcode il y a environ un an.
- l'autre utilisant Visual C++ il y a environ 15 ans.