On Thu, Aug 25, 2005 at 08:17:19AM +0200, Hanno 'Rince' Wagner wrote: > Steve Langasek schrieb am 24. August 2005:
> > > I fear I need the debug-Version of libc, not hylafax. > > Why? The backtrace you provided shows the segfault happens in hylafax code, > > not in glibc code. > Okay. I am not good in reading backtraces, but there are a lot of > "empty" lines which I tried to fill. But: these lines are not from > hylafax itself. (btw: hylafax or capi4hylafax? c2faxsend/recv are > from capi4hylafax...) The lines I see in the backtrace you provided for c2faxrecv are not from glibc, either; they're mostly null pointers, which probably points either to stack corruption or a problem with gdb. (And yes, I meant capi4hylafax, not hylafax itself.) The important line in any case is the one at the very top of the backtrace, and that's definitely in capi4hylafax. > > I think this will be very difficult to debug without line number > > information, but if I had the line number info in the backtrace I could > > probably spot the bug. > *nod* but even with non-stripped c2faxsend there is no information > about that. Yes, hence asking for a rebuild that explicitly enables debugging symbols, instead of just not stripping the binary. > I tried to send a fax to myself and in that way I got a coredump for > c2faxsend. Seems to be the same problem (also mentioned from other > people). The backtrace is as the following: > luggage:~# gdb /usr/bin/c2faxsend core.1677 > GNU gdb 6.3-debian > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "x86_64-linux"...Using host libthread_db > library "/usr/lib/debug/libthread_db.so.1". > Core was generated by `c2faxsend -f TIFF -d 2536215 > /var/spool/hylafax/docq/doc3.tif'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /usr/lib/debug/libpthread.so.0...done. > Loaded symbols for /usr/lib/debug/libpthread.so.0 > Reading symbols from /usr/lib/libtiff.so.4...done. > Loaded symbols for /usr/lib/libtiff.so.4 > Reading symbols from /usr/lib/libcapi20.so.2...done. > Loaded symbols for /usr/lib/libcapi20.so.2 > Reading symbols from /usr/lib/libz.so.1...done. > Loaded symbols for /usr/lib/libz.so.1 > Reading symbols from /usr/lib/libstdc++.so.5...done. > Loaded symbols for /usr/lib/libstdc++.so.5 > Reading symbols from /usr/lib/debug/libm.so.6...done. > Loaded symbols for /usr/lib/debug/libm.so.6 > Reading symbols from /usr/lib/debug/libc.so.6...done. > Loaded symbols for /usr/lib/debug/libc.so.6 > Reading symbols from /lib/libgcc_s.so.1...done. > Loaded symbols for /lib/libgcc_s.so.1 > Reading symbols from /lib/ld-linux-x86-64.so.2...Reading symbols > from /usr/lib/debug/lib/ld-2.3.2.so...done. > done. > Loaded symbols for /lib64/ld-linux-x86-64.so.2 > Reading symbols from /usr/lib/libjpeg.so.62...done. > Loaded symbols for /usr/lib/libjpeg.so.62 > #0 0x0000002a95ee3f3c in memcpy () from /usr/lib/debug/libc.so.6 > (gdb) bt > #0 0x0000002a95ee3f3c in memcpy () from /usr/lib/debug/libc.so.6 > #1 0x0000002a958e0062 in capi20_put_message () from /usr/lib/libcapi20.so.2 > #2 0x000000000041ac70 in CapiBase_PutMessage (Base=0x542740, > Message=0x543b100000 <Address 0x543b100000 out of bounds>) at > CapiBase.h:74 > #3 0x00000000004081f1 in CCAPI20_Channel::DataB3Req (this=0x407fe55e, > Params=0x543b100000) > at CapiMsg.h:353 > #4 0x000000000040fe08 in CTransferChannel::PutData (this=0x7fbfff7ed0, > Data=0x543b10 "Sfff\001", DataLength=2048, hDataID=0x2) at Channel.cpp:353 > #5 0x0000000000404ad1 in CFaxSend::SendData (this=0x7fbfff7ed0) at > faxsend.cpp:622 > #6 0x0000000000410f95 in CTransferChannel::ConnectB3ActiveInd > (this=0x7fbfff7ed0, > pNCPI=0x407ff3c0) at Channel.cpp:1094 > #7 0x0000000000408d49 in CCAPI20_Channel::CONNECT_B3_ACTIVE_IND > (this=0x7fbfff7ed0, > NCCI=2048, pNCPI=0x407ff3c0) at CapiChan.cpp:655 > #8 0x000000000040a67d in CCAPI20_MsgBase::HandleGetMessage > (this=0x7fbfff7ed0, > Message=0x54c8ae "\025") at osmem.h:116 > #9 0x000000000041ad99 in CapiBase_WaitForSignalThread (pice=0x542740) at > CapiBase.cpp:164 > #10 0x0000002a95671b55 in start_thread (arg=0x407fe55e) at > pthread_create.c:264 > #11 0x0000002a95f367f0 in thread_start () from /usr/lib/debug/libc.so.6 > #12 0x0000000000000000 in ?? () > #13 0x0000000000000000 in ?? () > #14 0x0000000000000000 in ?? () > #15 0x0000000000000000 in ?? () > #16 0x0000000000000000 in ?? () > #17 0x0000000000000000 in ?? () > #18 0x0000000000000000 in ?? () > #19 0x0000000000000000 in ?? () > #20 0x0000002a96085e00 in _nl_C_locobj () from /usr/lib/debug/libc.so.6 > [..] > is that more informative? Well, it appears to have debugging symbols (i.e., line numbers) for the capi4hylafax functions, but it doesn't actually look like it's related to the c2faxrecv bug you were reporting... -- 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
