Random crashes when setting locale data

[Yuri D'Elia]

Hi everyone.

I've stomped on a bug in either bash or gettext which is very difficult to 
reproduce and of course one that I cannot ignore.

The configuration is as follows: I'm running some calculations using "solar" (a 
bioinformatical program) which in turns calls "gunzip", which is implemented as 
a very short bash script:

#!/bin/bash
PATH=${GZIP_BINDIR-'/bin'}:$PATH
exec gzip -d "$@"

This script fails roughly 3% of the time for me, only when running on a loaded 
system, and then again only when run through "solar". I've tried to run bash 
manually reproducing the *exact* environment by dumping "env" but no luck.

I've rebuilt bash using the latest source version:

GNU bash, version 4.2.0(1)-release (x86_64-pc-linux-gnu)

using the following configuration:

 --with-curses --enable-largefile --prefix=/usr --infodir=/usr/share/info 
--mandir=/usr/share/man --host=x86_64-linux-gnu host_alias=x86_64-linux-gnu 
CC=gcc-4.4 CFLAGS="-O0 -g -ggdb3" YACC="bison -y" --with-included-gettext

I've copied the configuration from ubuntu's 10.4 LTS package (since that's what 
I'm using anyway - but I wanted to avoid their patches), but note that I've 
also tried rebuilding using gcc-4.6 with the same issue. I've also tried to 
rebuild several other bash versions (up to 4.1.x as in ubuntu) with the same 
issue. Also note that I'm building the bundled gettext and disabled 
optimizations for easier debugging.

All being set, I point PATH to a local copy of bash to get a decent stack trace:

Core was generated by `/home/ydelia/debug/bin/bash 
/home/ydelia/debug/bin/gunzip /home/ydelia/debug/file'.
Program terminated with signal 11, Segmentation fault.
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31
31      ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory.
        in ../sysdeps/x86_64/multiarch/../strlen.S
(gdb) where
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31
#1  0x00007f73230671dd in _nl_make_l10nflist (l10nfile_list=<value optimized 
out>, 
    dirlist=<value optimized out>, dirlist_len=<value optimized out>, 
    mask=<value optimized out>, language=<value optimized out>, 
    territory=<value optimized out>, codeset=0x7fff8fac0566 "UTF-8", 
    normalized_codeset=0x0, modifier=0x0, 
    filename=0x7f7323168e77 "LC_IDENTIFICATION", do_allocate=0) at 
l10nflist.c:200
#2  0x00007f73230606f3 in _nl_find_locale (
    locale_path=0x7f7323183f00 "/usr/lib/locale", locale_path_len=16, 
category=12, 
    name=<value optimized out>) at findlocale.c:145
#3  0x00007f732305fcf6 in *__GI_setlocale (category=12, locale=<value optimized 
out>)
    at setlocale.c:303
#4  0x000000000047cb20 in set_default_locale () at locale.c:71
#5  0x0000000000420e70 in main (argc=3, argv=0x7fff8fac08e8, env=0x7fff8fac0908)
    at shell.c:399

I also occasionally (less than 1% of the cases) get this gem:

/home/ydelia/debug/bash: xmalloc: variables.c:405: cannot allocate 61 bytes 
(16384 bytes allocated)

I'm starting to think that either there's a bug in libintl, or a corruption 
prior to set_default_locale. Running bash under valgrind doesn't seem to 
trigger any obvious problem.

Can you please help?

Thanks.