[arch-general] SIGSEGV in getopt, libc-problem?
ino-news at spotteswoode.dnsalias.org
Tue Jul 7 16:17:09 EDT 2009
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
$ 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)
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:
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
incomplete CFI data; unspecified registers (e.g., eax) at 0xb7fa838a...#0 0xb7fa84dc in _getopt_internal_r ()
#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.
More information about the arch-general