[arch-general] SIGSEGV in getopt, libc-problem?

[clemens fischer]

For a few days now I noticed some programs not working, like "lzma" or
"xz" from the "xz-utils".  They segfault and "xz --help" says:

  $ /usr/bin/xz --help
  /usr/bin/xz: unrecognized option '--'
  /usr/bin/xz: Try `/usr/bin/xz --help' for more information.

So I went to compile the original source, and the gdb(1) backtrace shows
them to die in "_getopt_internal()".  I thought my system to be
inconsistent somehow, because a friend reports these programs working.
I already re-installed the package.  It gets its libs from archlinux
package locations:

  $ ldd /usr/bin/xz
        linux-gate.so.1 =>  (0xb80a4000)
        liblzma.so.0 => /usr/lib/liblzma.so.0 (0xb806e000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb8056000)
        libc.so.6 => /lib/libc.so.6 (0xb7f0e000)
        /lib/ld-linux.so.2 (0xb80a5000)

It is possibly a problem with getopt_long().  Most programs work(!), ie.
I only noticed this with "xz", "lzma" and friends, both the packages and
hand-compiled versions.  I use the bash commandline all the time with
many programs calling getopt_long(), they all work.  Backtrace:

  (gdb) run
  Starting program: /home/src/bulk/lzma/xz/src/xz/xz
  Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
  Reading symbols from system-supplied DSO at 0xb8069000...(no debugging symbols found)...done.
  Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done.
  [Thread debugging using libthread_db enabled]
  Reading symbols from /lib/libc.so.6...
  (no debugging symbols found)...done.
  [New Thread 0xb7ef36c0 (LWP 32015)]

  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 0xb7ef36c0 (LWP 32015)]
  0xb7fa84dc in _getopt_internal_r () from /lib/libc.so.6
  (gdb) bt
  incomplete CFI data; unspecified registers (e.g., eax) at 0xb7fa838a...#0  0xb7fa84dc in _getopt_internal_r ()
     from /lib/libc.so.6
  #1  0xb7fa946e in _getopt_internal () from /lib/libc.so.6
  #2  0xb7fa96b9 in getopt_long () from /lib/libc.so.6
  #3  0x0804980d in parse_real ()
  #4  0x08049a07 in args_parse ()
  #5  0x0804b18e in main ()

  $ pac o /lib/libc.so.6
  /lib/libc.so.6 is owned by glibc 2.10.1-2
  $ ll /lib/libc[.-]*
  393476 -rwxr-xr-x 1 root root ? 1.6M 2009-05-23 05:54 /lib/libc-2.10.1.so*
  393470 lrwxrwxrwx 1 root root ?   14 2009-05-23 05:54 /lib/libc.so.6 -> libc-2.10.1.so*

Did somebody else observe something like this?  I already searched the
web ("_getopt_internal_r SIGSEGV"), but there's nothing specific,
although other programs had problems like this years ago.

Any pointers appreciated.


clemens