I get a Trace/BPT trap: 5 error when using the open command:

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

Any suggestions how I can narrow down what is causing this?

I understand from my earlier question, that it has to do with not finding a dynamic library - but which one and why is it not finding the library?

Fron the GUI, everything works fine, but is present from termnal as well as iTerm.

System: Macbook Pro Retina, Maverick

Any suggestions?


$ otool -L /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)


$ otool -L /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)

so I can't see anything missing?

  • What happens when you explicitly give open a path to TextEdit to ensure it launches the same bundle you specified in otool? Perhaps there is a second set of Apps mounted from an older system build? Also, have you compare your command line environment variables to a cleanly built user / system? – bmike Dec 10 '13 at 14:30
  • Explicit Path: was the same problem. But now, without restarting, is it working under Terminal, but noir under iTerm. I am sure this has to do with the environment variables. How can I check these? – Rainer Dec 10 '13 at 14:52
  • OK - there is a difference between PATH in Terminal and iTerm - how can I find the PATH for the GUI apps? – Rainer Dec 10 '13 at 15:05

I suspect you will by now have seen the problem reappear. The fix you described had a side-effect that ended up, for a time, solving the problem.

I believe that the problem had to do with the security context in which your terminal's shell was attempting to launch programs that try to connect to the window system.

My solution to this problem, whenever it has occurred from my Terminal.app shells, has been to use reattach-to-user-namespace (https://github.com/ChrisJohnsen/tmux-MacOSX-pasteboard). For example, at a bash prompt:

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...

When you rebooted as part of the fix you reported, it had the side-effect of creating a shell process whose connection to the security context of your windowed login session was not stale, as it had been before when the commands were failing with "Trace/BPT trap: 5". So although there might have been a real problem with the PATH setup, I believe it was the refreshing of the shell's process environment that was the true fix.

FWIW, I've got reattach-to-user-namespace installed via Homebrew.

  • It has reappeared a few days ago for one program (notmuch) installed via homebrew, but re-installing it via homebrew solved the problem. I keep your answer in mind, but I assume that it had different reasons on my side. – Rainer May 1 '14 at 9:05
  • 1
    The reattach-to-user-namespace solution from Tommy worked perfectly for me. Thank you. – Robin Zimmermann Sep 5 '14 at 20:55
  • I've since discovered that it appears - usually - to be sufficient just to create a new shell process. So, for example, 'exec bash -l' works. One at least one occasion that did not work, but retrying immediately with another 'exec bash -l' did the trick. I'm still convinced it has something to do with the launchd security context of the shell, but it doesn't after all require reattach-to-user-namespace. – Tommy Knowlton Sep 6 '14 at 22:57

It seems that the PATH variable was causing the problem.

Using iTerm, the PATH variable included unpredictable Unicode characters. I tracked it down to an entry which I added to the /etc/paths.d directory (the path $HOME/bin). It contained after the path a linefeed. By editing the fikle with nano, I did not manage to delete this Unicode(?) character, i.e. restarting did not solve the problem, but I used then Emacs and deleted all characters after the path (two characters shown as spaces which were not visible using nano) and added a RETURN.

Rebooted and it was working - and it still is.

Hope it stays like this.

Thanks for your input.

  • I had the same problem. It happened that I didn't add a new line character after the last path in /etc/paths. So when doing echo $PATH I was getting something like /bin:/usr/bin?:/another/path. Adding the new line lead to the usual /bin:/usr/bin:/another/path and restarting Terminal.app made it to take effect solving the problem :) – nacho4d May 22 '14 at 14:21
  • @ nacho4d : I am suffering from the same problem can't open any program from the terminal and getting the same error message. Could you please describe in more detail how to "Adding the new line lead to the usual " Sorry but I am not that experienced in bash/ shell stuff. Just want to open my vim again! If I type echo $ PATH I get the following: /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/git/bin:/usr/texbin – Max Lampe Mar 1 '15 at 10:44

I had the same problem.

I had a hidden file in /etc/paths.d/ that was confusing my PATH variable. I deleted the file and everything works as normal now.

FYI the file was an undo file generate by vim: .<original filename>.un~


Based on @Rainer suggestion, I found that some env variable contains a -, and some security feature killed my command (reasonable thing to do). Once I change - to a , my command proceeds without being killed.

No restart needed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .