Bug#339419: d4x crashes in strlen () from /lib64/libc.so.6

[Loïc Minier]

        Hi,

On Wed, Dec 21, 2005, Max Alekseyev wrote:
> They called libglib2.0-0-dbg and libgtk2.0-0-dbg here.

 Examining the second backtrace still doesn't point at them, my comments
 are below.

> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1098918240 (LWP 23033)]
> 0x00002aaaac900e60 in strlen () from /lib64/libc.so.6

 The segfault happens in Thread 1098918240...

> (gdb) info threads
> * 4 Thread 1098918240 (LWP 23033)  0x00002aaaac900e60 in strlen ()
>    from /lib64/libc.so.6

 ... which is thread 4.

>   3 Thread 1090525536 (LWP 23016)  0x00002aaaac9527b6 in select ()
>    from /lib64/libc.so.6

 Another thread is in select(), waiting for something to happen on some
 file descriptors.

>   2 Thread 1082132832 (LWP 23015)  0x00002aaaaabcbb6a in 
>   pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0

 That thread is waiting for a lock.

>   1 Thread 46912547122192 (LWP 23012)  0x00002aaaac950870 in poll ()
>    from /lib64/libc.so.6

 And that one is also waiting for some even on some file descriptor.

 There's one alive thread, thread 4, even if I can't tell whether you
 are running SMP.

> (gdb) bt
> #0  0x00002aaaac900e60 in strlen () from /lib64/libc.so.6

 The actual crash happens here, probably because a borken address was
 passed to strlen().

> #1  0x00002aaaac49670a in std::string::compare () from 
> /usr/lib/libstdc++.so.6

 This function probably only relayed the string to strlen().

> #2  0x0000000000455f2d in std::operator+<char, std::char_traits<char>, 
> std::allocator<char> > ()
> #3  0x0000000000438e84 in std::operator+<char, std::char_traits<char>, 
> std::allocator<char> > ()
> #4  0x000000000043af15 in std::operator+<char, std::char_traits<char>, 
> std::allocator<char> > ()
> #5  0x00002aaaaabc9b1c in start_thread () from /lib64/libpthread.so.0
> #6  0x00002aaaac959c22 in clone () from /lib64/libc.so.6
> #7  0x0000000000000000 in ?? ()

 Now for that part, I can't tell, but it looks like some strings were
 concatenated together.

 Could you please install libc6-dbg so that we see clearer in these
 calls?

 Also, would you rebuild d4x with debugging symbols as explained at
 <http://wiki.debian.org/HowToGetABacktrace>, that would confuse gdb
 less I suppose.

   Thanks,
-- 
Loïc Minier <lool at dooz.org>