Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Abort trap: 6" messages in bash #262

Open
fnl opened this issue Feb 1, 2019 · 8 comments
Open

"Abort trap: 6" messages in bash #262

fnl opened this issue Feb 1, 2019 · 8 comments

Comments

@fnl
Copy link

fnl commented Feb 1, 2019

All of a sudden, I am getting "Abort trap: 6" messages in my terminal after each command. Removing the "~/.z" database do not help and the issue persists restarts. Only disabling z (not sourcing z.sh) gets rid of the problem. I haven't plowed through the z.sh file to identify where the error message might be coming from, so any help welcome.

@rafi
Copy link

rafi commented Feb 12, 2019

Are you on a macOS? have you tried rebooting your machine?

@fnl
Copy link
Author

fnl commented Feb 12, 2019

Yes, and it didn't help.
But now, after several restarts, and without the old database, that message is gone again.
So just an annoying and seemingly not reproducible issue...

@rupa
Copy link
Owner

rupa commented Mar 21, 2019

feel free to re-open if this comes back or if you figure out what it was. This is likely an issue with a couple of poorly written things (my thing included) not interacting well.

@rupa rupa closed this as completed Mar 21, 2019
@mrmanc
Copy link

mrmanc commented Aug 20, 2019

I’m having this issue at the moment and can mitigate it by disabling z (v 1.9). Interestingly it only happens if I am not in my home directory. Not sure what I did to trigger it, but brew may have updated z.

@rupa
Copy link
Owner

rupa commented Aug 20, 2019

I think it's an interaction with something else maybe doing something like set -e before z gets called, or something else that messes with PROMPT_COMMAND or zsh equivalent. In any event z.sh isn't currently written such that a non-zero exit code from some line means there's an error and I have a suspicion something like that is being imposed.

Not surprising it doesn't happen in ~ cause z explicitly excludes that dir from tracking as it's already easy to get to.

are you using bash or zsh?

@rupa rupa reopened this Aug 20, 2019
mrmanc added a commit to mrmanc/z that referenced this issue Aug 22, 2019
@mrmanc
Copy link

mrmanc commented Aug 22, 2019

I use bash. Thanks for the tip. After sourcing z.sh I was ending up with this as my PROMPT_COMMAND: _jenv_export_hook;update_terminal_cwd;history -a; history -c; history -r;echo -ne "\033]0;$(hostname -s)\007" _z --add "$(command pwd -P 2>/dev/null)" 2>/dev/null;

Note the missing semicolon after my call to echo. I’ve opened a PR which needs review and testing, but should resolve this.

@rupa
Copy link
Owner

rupa commented Aug 22, 2019

ah, makes some sense. definitely a challenge to keep everything playing nice when other stuff is hooking in PROMPT_COMMAND
I think checking for this case and handling it in z.sh is worth doing, but if that echo guy is coming from another project you can file an issue with, might be worth nudging them to play nicer with others and semicolon terminate on their end

@mrmanc
Copy link

mrmanc commented Aug 22, 2019

Very good shout! It was actually my dotfiles that were omitting the semicolon. I’ve resolved that now. Typically, I checked that I had solved the semicolon with #269 but didn’t check that it resolved the Abort trap: 6 message. 🤦‍♂ So, I found a mistake that I made, tried to fix it in your project, and it wasn’t even relevant!

Running the actually _z --add "$(command pwd -P 2>/dev/null)" 2>/dev/null; bit on it’s own was gave me this error:

dyld: Library not loaded: /usr/local/opt/readline/lib/libreadline.7.dylib
  Referenced from: /usr/local/bin/awk
  Reason: image not found
Abort trap: 6

A little Googling suggested upgrading gawk,
from 4.2.1 to 5.0.1 and that has resolved this issue. I also upgraded bash to 5.0.9 along the way while trying to fix this in case that’s relevant.

Thanks for your help. You may wish to close this. I have an improvement to #269 which feels sensible but that isn’t relevant to this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants