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 <[EMAIL PROTECTED]>