Configuration Information:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wall
uname output: 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)
x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.3
Patch Level: 33
Release Status: release

On the system which doesn't provide any locale (other than default, POSIX
one), Bash is hit with a segfault after the following is executed (I fork
into another Bash instance so the error about the segfault is clearly

        # bash
        # echo ${LANG:-foobar}
        # LANG=UTF-8
        # printf '%s\n' $'\u013b'
        # printf '%s\n' $'\u013c'
        # unset LANG
        Segmentation fault (core dumped)
        # type printf
        printf is a shell builtin

Note that this happens either after call to printf or echo is made. Also,
if I call printf before LANG is set, segfault doesn't happen after the
above is performed:

        # bash
        # printf '%s\n' $'\u013b'
        # LANG=UTF-8
        # printf '%s\n' $'\u013b'
        \u013B # should that return a proper char at this point instead?
        # unset LANG
        # : # everything works just fine
Creating /usr/lib/locale/{UTF-8,whatever_LANG_is_set_to}/LC* on the target
system seems to fix the issue, but still, the way how Bash reacts to LANG
being unset looks a bit buggy. Reproduced locally with the fresh build of
4.4.19(1)-release as well.

Reply via email to