testsuite: Fix uname() during glibc startup
authorMichal Marek <mmarek@suse.cz>
Thu, 6 Mar 2014 17:03:46 +0000 (18:03 +0100)
committerLucas De Marchi <lucas.demarchi@intel.com>
Fri, 7 Mar 2014 02:09:56 +0000 (23:09 -0300)
commit632fb7b4634a540bb09af3b2004b3fe44cd4a214
tree02111cff59455d76445bcb3b21e82a32db47d6a1
parent3be5bf464658ec4b7134768feca598fd008d8d21
testsuite: Fix uname() during glibc startup

In a specific configuration (chroot with the linux32 personality), the
modprobe_install_cmd_loop test failed, because the bash process handling
the install command segfaulted. The backtrace showed a uname() call
during libpthread initialization, at which point the environ pointer
hadn't been initialized yet:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x080c1591 in getenv (name=<optimized out>,
    name@entry=0xf775f850 "TESTSUITE_UNAME_R") at getenv.c:81
81       for (i = 0, len = strlen (name); environ[i]; i++)
(gdb) bt
#0  0x080c1591 in getenv (name=<optimized out>,
    name@entry=0xf775f850 "TESTSUITE_UNAME_R") at getenv.c:81
#1  0xf775f754 in uname (u=u@entry=0xff946350) at testsuite/uname.c:32
#2  0xf74ffc6c in is_smp_system ()
    at ../nptl/sysdeps/unix/sysv/linux/i386/smp.h:39
#3  __pthread_initialize_minimal_internal () at nptl-init.c:460
#4  0xf74fe32c in _init () at ../sysdeps/i386/crti.S:74
#5  0x00000000 in ?? ()
(gdb) p environ
$1 = (char **) 0x0

I don't know why it only happend in the chroot, but glibc can call its
own functions and impose any restrictions before main() is started, so
we have to adapt.

Also, do not return error if there is an environment, but the
environment variable is not found. If uname() is called by kmod, then
the respective test will simply fail later. If it's something else
calling uname(), then we do not want to disturb the program.
testsuite/uname.c