On Wed, Dec 21, 2005 at 01:58:13PM +0100, Loïc Minier wrote: > > (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? All that will do is let you look at the value passed to strlen(); it won't tell you much about why it's wrong or where it came from. > Also, would you rebuild d4x with debugging symbols as explained at > <http://wiki.debian.org/HowToGetABacktrace>, that would confuse gdb > less I suppose. I didn't see much evidence here that gdb was confused? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
