bash @4.2.45_2 - Segmentation Fault when executing undefined command

[onitsuka42@…]

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

[onitsuka42@…]

Cc Me!

[onitsuka42@…]

Sorry I can't edit the ticket to fix the formatting.

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

[mf2k (Frank Schima)]

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.

[raimue (Rainer Müller)]

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?

[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

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

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

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

[macports@…]

Cc Me!

[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

[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:

1. Configure your bash binary (preferably with debug symbols) as your login shell
2. ssh $LOGNAME@localhost; get the PID of the shell with echo $$
3. Attach to the process gdb -p <pid>; set breakpoint; continue
4. Type dummy and step through the program in gdb

[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

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

[exg (Emanuele Giaquinta)]

Cc Me!

[mmpestorich (Mike M Pestorich)]

Cc Me!

[kajh]

Cc Me!

[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]~$

[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

[gorticus (Jason Mitchell)]

Replying to jason-macports@…:

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

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 ''
$ _

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