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
Description:
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
visible):
Repeat-By:
# bash
# echo ${LANG:-foobar}
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'
\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
Fix:
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.
