[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Random crashes when setting locale data

From: Yuri D'Elia
Subject: Random crashes when setting locale data
Date: Wed, 2 Nov 2011 20:37:35 +0100

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:

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 
    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 
#2  0x00007f73230606f3 in _nl_find_locale (
    locale_path=0x7f7323183f00 "/usr/lib/locale", locale_path_len=16, 
    name=<value optimized out>) at findlocale.c:145
#3  0x00007f732305fcf6 in *__GI_setlocale (category=12, locale=<value optimized 
    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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]