Ticket #25693 (closed defect: fixed)
bash-4.1.7, login shell crash, EXC_BAD_INSTRUCTION
| Reported by: | macports@… | Owned by: | raimue@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 1.9.1 |
| Keywords: | Cc: | ||
| Port: | bash |
Description
For undefined reason my bash version 4.1.7 from macports crashed by an login shell. If I'm using bash without a login shell everything works fine.
Example:
# Doesn't work, and fall back to the normal shell output misterx $ sudo su - misterx $ # Work correctly misterx $ sudo su root $
I've no .bashrc, .bash_profile or other files around that could be kill the login shell.
The crash report is attached to the ticket, and it looks like something going wrong with the dynamic libs but rebuild 'bash' has no effect.
Attachments
Change History
Changed 3 years ago by macports@…
- Attachment bash_2010-07-13-131423_localhost.crash added
comment:1 Changed 3 years ago by macsforever2000@…
- Owner changed from macports-tickets@… to raimue@…
comment:3 Changed 3 years ago by raimue@…
I am unable to reproduce this issue as described above. But I was able to reproduce when bash is being used as a login shell /opt/local/bin/bash -l in iTerm (while it does work fine in Terminal.app).
Apparently this has something to do with closing file descriptors. From reading the source, bash attempts to close fds 3 to 20 if started as a login shell (why?). So I can only guess that this has something to do with the forking process leaving fds open in this range.
comment:4 Changed 3 years ago by macports@…
I've uninstalled all port files and reinstalled macports from scratch. After the new installation i couldn't reproduce the problem any more. Currently i've also tested iTerm with the login shell /opt/local/bin/bash -l and it's also working.
comment:5 Changed 3 years ago by raimue@…
- Status changed from assigned to closed
- Resolution set to fixed
Fixed in r70914, as discussed on bash-bug.


bash, crash report 2010-07-13-131423