Comment déboguer le piège Trace / BPT: 5?

7

J'ai un Trace/BPT trap: 5 erreur lors de l'utilisation de la commande open: 

$ open -a Emacs
Trace/BPT trap: 5
$ open -a Safari 
Trace/BPT trap: 5
$ open -a TextEdit
Trace/BPT trap: 5

Des suggestions sur la façon dont je peux réduire la cause?

D'après ma question précédente, je comprends que cela a à voir avec le fait de ne pas trouver une bibliothèque dynamique - mais laquelle et pourquoi ne trouve-t-elle pas la bibliothèque?

Depuis l'interface graphique, tout fonctionne bien, mais est présent depuis le terminal ainsi que dans iTerm.

Système: Macbook Pro Retina, Maverick

Aucune suggestion?

INFORMATION ADDITIONNELLE: 

$ otool -L /Applications/TextEdit.app/Contents/MacOS/TextEdit
/Applications/TextEdit.app/Contents/MacOS/TextEdit:
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 20.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1056.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 59.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.11.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1251.0.0)
/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 600.0.0)

et 

$ otool -L /Applications/Emacs.app/Contents/MacOS/Emacs-10.7 
/Applications/Emacs.app/Contents/MacOS/Emacs-10.7:
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1138.47.0)
/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.3.0)
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 53.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 635.21.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 41.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 833.25.0)

donc je ne vois rien qui manque?

terminal mavericks Rainer
la source
Que se passe-t-il lorsque vous indiquez explicitement un chemin d'accès à TextEdit afin de garantir qu'il lance le même ensemble que celui spécifié dans otool? Peut-être existe-t-il un deuxième ensemble d'applications montées à partir d'une ancienne version du système? De même, avez-vous comparé vos variables d’environnement de ligne de commande à un utilisateur / système proprement construit?
bmike
Chemin explicite: était le même problème. Mais maintenant, sans redémarrer, fonctionne-t-il sous Terminal, mais noir sous iTerm. Je suis sûr que cela a à voir avec les variables d'environnement. Comment puis-je vérifier ceux-ci?
Rainer
OK - il y a une différence entre PATH dans Terminal et iTerm - comment puis-je trouver le PATH pour les applications à interface graphique?
Rainer

Réponses:

2

Je suppose que vous avez déjà vu le problème réapparaître. Le correctif que vous avez décrit a eu un effet secondaire qui a fini par résoudre le problème pendant un certain temps.

Je pense que le problème est lié au contexte de sécurité dans lequel le shell de votre terminal tente de lancer des programmes qui tentent de se connecter au système de fenêtre.

Ma solution à ce problème, chaque fois que cela se produisait depuis mes shells Terminal.app, consistait à utiliser l'espace de nommage réattaché-à-utilisateur ( https://github.com/ChrisJohnsen/tmux-MacOSX-pasteboard ). Par exemple, à l'invite bash: 

tk-mbp:~ tommy$ wstorm Projects/my-webapp
Trace/BPT trap: 5
tk-mbp:~ tommy$ exec reattach-to-user-namespace -l bash
(reading ~/.bash_profile)
tk-mbp:~ tommy$ wstorm Projects/my-webapp
tk-mbp:~ tommy$ # that worked...

Lorsque vous avez redémarré dans le cadre du correctif que vous avez signalé, il a eu pour effet secondaire de créer un processus shell dont la connexion au contexte de sécurité de votre session avec une fenêtre de connexion n’était pas périmée, comme c / Piège BPT: 5 ". Donc, bien qu'il y ait peut-être eu un réel problème avec la configuration de PATH, je pense que c'est l'actualisation de l'environnement de processus du shell qui a été la vraie solution.

FWIW, j'ai installé un espace de noms «rattachez-à-l'utilisateur» via Homebrew.

Tommy Knowlton
la source
Il a réapparu il y a quelques jours pour un programme (pas beaucoup) installé via homebrew, mais sa réinstallation via homebrew a résolu le problème. Je garde votre réponse à l’esprit, mais je suppose qu’elle avait des raisons différentes de mon côté.
Rainer
1
La solution d'espace de noms réattachée à l'utilisateur de Tommy a parfaitement fonctionné pour moi. Je vous remercie.
Robin Zimmermann
J'ai depuis découvert que cela semblait - en général - suffire pour créer un nouveau processus shell. Ainsi, par exemple, "exec bash -l" fonctionne. Au moins une occasion qui n’a pas fonctionné, mais réessayer immédiatement avec un autre "exec bash -l" a fait l'affaire. Je suis toujours convaincu que cela a quelque chose à voir avec le contexte de sécurité launchd du shell, mais après tout, il ne nécessite pas d'espace de rattachement rattache à utilisateur.
Tommy Knowlton
1

Il semble que la variable PATH était à l'origine du problème.

À l'aide d'iTerm, la variable PATH incluait des caractères Unicode imprévisibles. Je l'ai retrouvé dans une entrée que j'ai ajoutée à la /etc/paths.d répertoire (le chemin $HOME/bin ). Il contenait après le chemin un saut de ligne. En modifiant le fikle avec nano, je n’ai pas réussi à supprimer ce caractère Unicode (?), C’est-à-dire que le redémarrage n’a pas résolu le problème, mais j’ai ensuite utilisé Emacs et supprimé tous les caractères après le chemin (deux caractères affichés comme des espaces non visibles). en utilisant nano) et ajouté un retour.

Redémarré et cela fonctionnait - et il est toujours.

J'espère que ça reste comme ça.

Merci pour votre contribution.

Rainer
la source
J'ai eu le même problème. Il m'est arrivé de ne pas ajouter de caractère de nouvelle ligne après le dernier chemin de /etc/paths. Alors quand echo $PATH Je recevais quelque chose comme /bin:/usr/bin?:/another/path. Ajout de la nouvelle ligne mène à l'habituel /bin:/usr/bin:/another/path et le redémarrage de Terminal.app l'a fait prendre en compte pour résoudre le problème :)
nacho4d
@ nacho4d: Je souffre du même problème. Je ne peux ouvrir aucun programme du terminal et obtenir le même message d'erreur. Pourriez-vous s'il vous plaît décrire plus en détail comment "Ajouter la nouvelle ligne mène à l'habituel" Désolé mais je ne suis pas expérimenté dans les choses bash / shell. Je veux juste ouvrir à nouveau mon vim! Si je tape echo $ PATH, je reçois le texte suivant: / usr / local / bin: / usr / bin: / bin: / usr / sbin: / sbin: / usr / local / git / bin: / usr / texbin
Max Lampe
1

J'ai eu le même problème.

J'avais un fichier caché dans /etc/paths.d/ c'était déroutant ma variable PATH. J'ai supprimé le fichier et tout fonctionne normalement.

Pour info, le fichier était un fichier d'annulation généré par vim: .<original filename>.un~

alidrongo
la source