SIGSEGV in getopt, libc-problem?

[clemens fischer-3]

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

[Daenyth Blank]

On Tue, Jul 7, 2009 at 16:17, clemens
fischer<ino-news@...> 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:
Are you using [testing]? When is the last time you updated those
programs and/or libraries?

[Gerardo Exequiel Pozzi-3]

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

[clemens fischer-3]

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

[clemens fischer-3]

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

[Patrick Brisbin]

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

[Daenyth Blank]

On Wed, Jul 8, 2009 at 18:09, Patrick Brisbin<pbrisbin@...> 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]

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@...> 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

[Allan McRae-3]

Daenyth Blank wrote:

> On Wed, Jul 8, 2009 at 18:09, Patrick Brisbin<pbrisbin@...> 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-3]

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