Opened 11 years ago
Last modified 7 months ago
#41248 assigned defect
bash @4.2.45_2 - Segmentation Fault when executing undefined command
Reported by: | onitsuka42@… | Owned by: | raimue (Rainer Müller) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.2.1 |
Keywords: | Cc: | macports@…, exg (Emanuele Giaquinta), mmpestorich (Mike M Pestorich) | |
Port: | bash |
Description (last modified by mf2k (Frank Schima))
When executing any undefined command in bash 4.2.45_2, I get a segmentation fault: 11
$ echo "test" test $ dummy Segmentation fault: 11
I generated a core dump for this segmentation fault, here are the details I extracted from it :
$ lldb (lldb) target create -core core.7288 error: core.7288 is a corrupt mach-o file: load command 72 LC_SEGMENT_64 has a fileoff + filesize (0x1d602000) that extends beyond the end of the file (0x1d601000), the segment will be truncated error: core.7288 is a corrupt mach-o file: load command 73 LC_SEGMENT_64 has a fileoff (0x1d602000) that extends beyond the end of the file (0x1d601000) Core file '/Users/romain/Desktop/tmp/core.7288' (x86_64) was loaded. Process 0 stopped * thread #1: tid = 0x0000, 0x00007fff9358d206 libdispatch.dylib`_dispatch_wakeup + 100, stop reason = signal SIGSTOP frame #0: 0x00007fff9358d206 libdispatch.dylib`_dispatch_wakeup + 100 libdispatch.dylib`_dispatch_wakeup + 100: -> 0x7fff9358d206: movq %rbx, 16(%rax) 0x7fff9358d20a: jmp 0x7fff9358d217 ; _dispatch_wakeup + 117 0x7fff9358d20c: movq %r14, %rdi 0x7fff9358d20f: movq %rbx, %rsi (lldb) thread backtrace all * thread #1: tid = 0x0000, 0x00007fff9358d206 libdispatch.dylib`_dispatch_wakeup + 100, stop reason = signal SIGSTOP frame #0: 0x00007fff9358d206 libdispatch.dylib`_dispatch_wakeup + 100 frame #1: 0x00007fff9358d7a8 libdispatch.dylib`_dispatch_queue_push_list_slow2 + 30 frame #2: 0x00007fff93590145 libdispatch.dylib`_dispatch_mach_msg_send + 608 frame #3: 0x00007fff9358fe99 libdispatch.dylib`dispatch_mach_send + 136 frame #4: 0x00007fff892d0864 libxpc.dylib`_xpc_connection_send_message_with_reply_f + 125 frame #5: 0x00007fff892d0724 libxpc.dylib`xpc_connection_send_message_with_reply_sync + 180 frame #6: 0x00007fff85fd6193 CoreFoundation`-[CFPrefsPlistSource copyReplyForDaemonMessage:toConnection:error:] + 243 frame #7: 0x00007fff86130820 CoreFoundation`__47-[CFPrefsPlistSource alreadylocked_synchronize]_block_invoke_2 + 352 frame #8: 0x00007fff85fd5a9b CoreFoundation`withDaemonConnection + 299 frame #9: 0x00007fff85fd54fb CoreFoundation`-[CFPrefsPlistSource alreadylocked_synchronize] + 587 frame #10: 0x00007fff85fd51f3 CoreFoundation`_copyValueForKey + 131 frame #11: 0x00007fff85fd5147 CoreFoundation`-[CFPrefsPlistSource copyValueForKey:] + 71 frame #12: 0x00007fff85fd4fa5 CoreFoundation`-[CFPrefsSearchListSource alreadylocked_copyValueForKey:] + 149 frame #13: 0x00007fff85fd4edf CoreFoundation`-[CFPrefsSource copyValueForKey:] + 79 frame #14: 0x00007fff85fd4e70 CoreFoundation`__CFPreferencesCopyAppValue_block_invoke + 32 frame #15: 0x00007fff85fcf04e CoreFoundation`+[CFPrefsSearchListSource withSearchListForIdentifier:perform:] + 846 frame #16: 0x00007fff85fcecb8 CoreFoundation`CFPreferencesCopyAppValue + 168 frame #17: 0x000000010eaa0598 libintl.8.dylib`_nl_language_preferences_default + 70 frame #18: 0x000000010ea9e9ea libintl.8.dylib`libintl_dcigettext + 894 frame #19: 0x000000010e994f71 bash`execute_command_internal + 13351 frame #20: 0x000000010e991af4 bash`execute_command + 92 frame #21: 0x000000010e983993 bash`reader_loop + 519 frame #22: 0x000000010e983052 bash`main + 5994 frame #23: 0x00007fff8c5905fd libdyld.dylib`start + 1
Once I exit lldb, the issue is solved and now undefined command execution doesn't segfault, but fails properly :
$ dummy -bash: dummy : command not found
Change History (21)
comment:1 Changed 11 years ago by onitsuka42@…
Cc: | onitsuka42@… added |
---|
comment:3 Changed 11 years ago by onitsuka42@…
I may have found what's causing the issue.
It happens when connecting using ssh and seems to be related to the fact that LC_ALL is undefined.
comment:4 Changed 11 years ago by mf2k (Frank Schima)
Cc: | onitsuka42@… removed |
---|---|
Description: | modified (diff) |
Keywords: | bash segfault lldb core removed |
Owner: | changed from macports-tickets@… to raimue@… |
Port: | bash added |
In the future, please fill in the Port field and Cc the port maintainers (port info --maintainers bash
), but not yourself since the reporter is automatically Cc'ed.
comment:5 Changed 11 years ago by raimue (Rainer Müller)
Status: | new → assigned |
---|
I am unable to reproduce this issue on OS X 10.9 Mavericks using bash @4.2.45_2. I tried using ssh, unsetting LC_ALL
and LANG
before, avoiding SendEnv
and more. Please provide more specific instructions for reproduction.
Do you define any custom function for command_not_found_handle
in your .bashrc? Can you reproduce the bug without your .bashrc/.bash_profile/.profile?
comment:6 Changed 11 years ago by onitsuka42@…
i don't have a .bashrc
nothing in .bash_profile but the macports PATH override
i connected over ssh from a Windows machine using last version of putty
comment:7 Changed 11 years ago by raimue (Rainer Müller)
Since the backtrace you showed points to libdispatch it would at least be helpful if you told us the version of OS X you are using. What you told me is still no recipe for reproduction. For example, I guess you had to configure bash as your login shell?
This bug seems similar to the one reported in #41112. The backtrace and the similar bug in another software makes me assume it's actually a bug in gettext when determining the system's language.
comment:8 Changed 11 years ago by onitsuka42@…
I have the issue using OS X 10.9 Maverick.
Here are the steps :
- install bash using macports
- configure it as the default shell
- enable sshd
- connect from Windows using putty to the mac.
- in my case when the connection is established I see that there is no LC_ALL in the env
- if I force LC_ALL in bashrc, I don't have the issue anymore.
Yes I guess the segfault is caused by the last gettext version of macports which seems to not be able to perform the error message translation in this case.
comment:9 Changed 11 years ago by macports@…
Hey all -- I'd like to confirm that I'm also having this under OSX Mavericks:
sphynx:~ dmahoney$ sw_vers ProductName: Mac OS X ProductVersion: 10.9.1 BuildVersion: 13B42
Also connected via putty so don't have an LC_ALL set.
I'd like to offer to test any debugs or capture any other info you guys may need to debug this. macports [at] gushi org.
comment:11 Changed 11 years ago by oclinux@…
Same problem here, gentoo prefix & bash --version GNU bash, version 4.2.39(1)-release (x86_64-apple-darwin13)
I've found a workaround for my case, just run:
trap [a-z]
where [a-z] is any char. The segfault will stop after that command. This command just run trap and return a signal == 2, so its not a trap, just a call. After that call, my segfaults stops when calling a function/binary that doesnt exist.
Hope that helps
comment:12 Changed 11 years ago by raimue (Rainer Müller)
As I commented earlier in #41112, I think this is actually a issue with gettext not able to determine the system langugage. It seems like this is only exposed in an non-graphical session over SSH without LC_ALL/LANG
in the environment. I tried to track it down with a debugger attached, but I have not been successful to confirm this so far.
Reproduction:
- Configure your bash binary (preferably with debug symbols) as your login shell
ssh $LOGNAME@localhost
; get the PID of the shell withecho $$
- Attach to the process
gdb -p <pid>
; set breakpoint; continue - Type
dummy
and step through the program in gdb
comment:13 Changed 10 years ago by exg (Emanuele Giaquinta)
This is the same bug as
http://article.gmane.org/gmane.os.macosx.fink.devel/21882
bash calls 'gettext' in the child process to print the 'command not found' error, and 'gettext' may call the function 'CFPreferencesCopyAppValue', which is not async-signal-safe. In particular, the bug happens if LC_ALL, LC_MESSAGES and LANG are all not set and 'gettext' is called for the first time in a child process (because otherwise CFPreferencesCopyAppValue is not called as the result is cached). See
http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/intl/langprefs.c#n234
http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/intl/dcigettext.c#n1534
comment:14 Changed 10 years ago by tanner@…
I was able reproduce the same problem running GNU tar as a different user ("su - user") which didn't have LANG set. Adding "export LANG=..." to the users .profile fixed it.
comment:16 follow-up: 17 Changed 10 years ago by mmpestorich (Mike M Pestorich)
Cc: | mmpestorich@… added |
---|
Cc Me!
comment:18 Changed 9 years ago by decibel (Jim Nasby)
I have the same problem on OS X 10.9.5. However, if I run a second bash the problem goes away:
decibel@decina:[20:39]~$uname -a Darwin decina.local 13.4.0 Darwin Kernel Version 13.4.0: Wed Mar 18 16:20:14 PDT 2015; root:xnu-2422.115.14~1/RELEASE_X86_64 x86_64 decibel@decina:[20:39]~$aoeu Segmentation fault: 11 decibel@decina:[20:39]~$bash decibel@decina:[20:39]~$oaeu bash: oaeu: command not found decibel@decina:[20:39]~$
comment:19 follow-ups: 20 21 Changed 8 years ago by gorticus (Jason Mitchell)
I have this problem without ssh
, using bash @4.3.46_0
on 10.10.5 (14F1808), when running in the terminal (both Terminal
and iTerm
v3). Explicitly setting LANG
solves it for me:
$ export LANG=en_US.utf8 $ /opt/local/bin/bash $ dummy bash: dummmy: command not found $ unset LANG $ dummy Segmentation fault: 11
comment:20 Changed 8 years ago by gorticus (Jason Mitchell)
Replying to jason-macports@…:
I have this problem without
ssh
, usingbash @4.3.46_0
on 10.10.5 (14F1808), when running in the terminal (bothTerminal
andiTerm
v3). Explicitly settingLANG
solves it for me:$ export LANG=en_US.utf8 $ /opt/local/bin/bash $ dummy bash: dummmy: command not found $ unset LANG $ dummy Segmentation fault: 11
A friendlier setting that works the same and prevents tool complaints about fallback, e.g.,
$ perl -e '' perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset), LANG = "en_US.utf8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). $ _
is
$ export LC_ALL=C $ perl -e '' $ _
comment:21 Changed 8 years ago by raimue (Rainer Müller)
Replying to jason-macports@…:
$ export LANG=en_US.utf8
That would be an invalid setting. Make that LANG=en_US.UTF-8
(as seen in the output of locale -a
). The .utf8
variant usually comes from Linux systems with glibc, where both versions would be equivalent.
Cc Me!