[arch-general] SIGSEGV in getopt, libc-problem?
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
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: Are you using [testing]? When is the last time you updated those
On Tue, Jul 7, 2009 at 16:17, clemens fischer<ino-news@spotteswoode.dnsalias.org> wrote: programs and/or libraries?
Daenyth Blank wrote:
Are you using [testing]? When is the last time you updated those programs and/or libraries?
I had [testing] for a while, only for testing some X11 libs back when I had a problem with a trackball. I stopped using it about a week ago, but I think there's no package left on my system. BTW: what's the pacman command to list the packages one has installed from a certain repo? The closest I can think of is: $ pacman -Qm csup 20060318-5 ddcxinfo-arch 0.8-2 dstat 0.6.9-1 libfetch 2.20-1 lshwd 1.1.3-5 opera 9.64-1 ttf-code2000 1.171-1 yaourt 0.9.2.4-1 I badly miss the repo-origin in the "pacman -Qi ..." output. Do you think one of these packages could influence my "xz" problem? clemens
On 07/08/09 at 11:31pm, clemens fischer wrote:
BTW: what's the pacman command to list the packages one has installed from a certain repo?
i use a bash alias for this: $ pacman -Sql testing | xargs pacman -Q 2>/dev/null i don't think there's an official option -- patrick brisbin
On Wed, Jul 8, 2009 at 18:09, Patrick Brisbin<pbrisbin@gmail.com> wrote:
i use a bash alias for this:
$ pacman -Sql testing | xargs pacman -Q 2>/dev/null
i don't think there's an official option
-- patrick brisbin
That doesn't tell you if it's FROM testing, only if you have a package installed with the same name as a package currently in testing.
oh duh, didn't realize that. i always have testing enabled so this works for me, his situation is different. sorry, ignore that. On 07/08/09 at 06:47pm, Daenyth Blank wrote:
On Wed, Jul 8, 2009 at 18:09, Patrick Brisbin<pbrisbin@gmail.com> wrote:
i use a bash alias for this:
$ pacman -Sql testing | xargs pacman -Q 2>/dev/null
i don't think there's an official option
-- patrick brisbin
That doesn't tell you if it's FROM testing, only if you have a package installed with the same name as a package currently in testing.
-- patrick brisbin
Daenyth Blank wrote:
On Wed, Jul 8, 2009 at 18:09, Patrick Brisbin<pbrisbin@gmail.com> wrote:
i use a bash alias for this:
$ pacman -Sql testing | xargs pacman -Q 2>/dev/null
i don't think there's an official option
-- patrick brisbin
That doesn't tell you if it's FROM testing, only if you have a package installed with the same name as a package currently in testing.
pacman -S pacman-contrib paclist testing
clemens fischer wrote:
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)
Compare with me $ md5sum /usr/lib/liblzma.so.0 /lib/libpthread.so.0 /lib/libc.so.6 /lib/ld-linux.so.2 /usr/bin/xz 72cd526ea4ee299f5c9eb1b49180d163 /usr/lib/liblzma.so.0 e12a37058b6360660658ad2bd26c2b57 /lib/libpthread.so.0 2a1cf98f035403805ae860b95fd8e995 /lib/libc.so.6 5db9051e70520777209f5368fb5d975b /lib/ld-linux.so.2 6f9d136415196e8547d3366d5f1d6139 /usr/bin/xz $ pacman -Qo /usr/lib/liblzma.so.0 /lib/libpthread.so.0 /lib/libc.so.6 /lib/ld-linux.so.2 /usr/bin/xz /usr/lib/liblzma.so.0 is owned by xz-utils 4.999.8beta-4 /lib/libpthread.so.0 is owned by glibc 2.10.1-2 /lib/libc.so.6 is owned by glibc 2.10.1-2 /lib/ld-linux.so.2 is owned by glibc 2.10.1-2 /usr/bin/xz is owned by xz-utils 4.999.8beta-4
Any pointers appreciated.
clemens
-- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Gerardo Exequiel Pozzi wrote:
Compare with me
$ md5sum /usr/lib/liblzma.so.0 /lib/libpthread.so.0 /lib/libc.so.6 /lib/ld-linux.so.2 /usr/bin/xz 72cd526ea4ee299f5c9eb1b49180d163 /usr/lib/liblzma.so.0 e12a37058b6360660658ad2bd26c2b57 /lib/libpthread.so.0 2a1cf98f035403805ae860b95fd8e995 /lib/libc.so.6 5db9051e70520777209f5368fb5d975b /lib/ld-linux.so.2 6f9d136415196e8547d3366d5f1d6139 /usr/bin/xz
$ pacman -Qo /usr/lib/liblzma.so.0 /lib/libpthread.so.0 /lib/libc.so.6 /lib/ld-linux.so.2 /usr/bin/xz /usr/lib/liblzma.so.0 is owned by xz-utils 4.999.8beta-4 /lib/libpthread.so.0 is owned by glibc 2.10.1-2 /lib/libc.so.6 is owned by glibc 2.10.1-2 /lib/ld-linux.so.2 is owned by glibc 2.10.1-2 /usr/bin/xz is owned by xz-utils 4.999.8beta-4
Thank's for checking. The info on my system matches yours. clemens
On Tue-2009/07/07-22:17 clemens fischer wrote:
(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 ()
A much simpler way to get at the same info is by using extra/ltrace: $ ltrace -Sif -A9 -n4 /usr/bin/xz ... [0x804a020] sysconf(76, 0, 3, 0, 0) = -1 [0x8049c63] strrchr("/usr/bin/xz", '/') = "/xz" [0x8049c7b] strstr("xz", "lz") = NULL [0x8049c96] strstr("xz", "cat") = NULL [0x8049e94] strstr("xz", "un") = NULL [0x8049cbb] getenv("XZ_OPT") = "-9" [0x804e097] strlen("-9") = 2 [0x804e058] realloc(NULL, 3) = 0x09f92868 [0x804e0ba] memcpy(0x09f92868, "-9", 3) = 0x09f92868 [0x8049ce4] __ctype_b_loc() = 0xb7d5a68c [0x804e058] realloc(NULL, 12) = 0x09f92878 [0x8049d6e] __ctype_b_loc() = 0xb7d5a68c [0x80495b4] getopt_long(2, 0x09f92878, "cC:defF:hHlkM:qrS:tT:vVz01234567"..., 0x0804e520, NULL) = 57 [0x80495b4] getopt_long(2, 0x09f92878, "cC:defF:hHlkM:qrS:tT:vVz01234567"..., 0x0804e520, NULL) = -1 [0x8049de4] free(0x09f92878) = <void> [0x8049def] free(0x09f92868) = <void> [0x80495b4] getopt_long(1, 0xbfdb4004, "cC:defF:hHlkM:qrS:tT:vVz01234567"..., 0x0804e520, NULL <unfinished ...> [0xb7e0e3cc] --- SIGSEGV (Segmentation fault) --- [0xffffffff] +++ killed by SIGSEGV +++ I left out a lot of cruft, but it shows where the program busts. clemens
participants (5)
-
Allan McRae
-
clemens fischer
-
Daenyth Blank
-
Gerardo Exequiel Pozzi
-
Patrick Brisbin