According to J. op den Brouw:
> I hope this is what you want....
Yup, that's a backtrace all right! My mistake about the name of the
executable. t_htnet is a shell script, which calls the testnet binary.
Fortunately, gdb was smart enough to figure this out from the executable
name in the core dump.
> #0 0x23ee0 in Connection::Timeout (this=0x4000, value=10) at Connection.cc:163
> 163 return oval;
>
> (gdb) bt
> #0 0x23ee0 in Connection::Timeout (this=0x4000, value=10) at Connection.cc:163
> #1 0x2670c in HtHTTP::HTTPRequest (this=0x40017d40) at HtHTTP.cc:216
> #2 0x26524 in HtHTTP::Request (this=0x40017d40) at HtHTTP.cc:159
> #3 0x23934 in Retrieve () at testnet.cc:388
> #4 0x22c50 in main (ac=1073759154, av=0x0) at testnet.cc:139
> (gdb) quit
> [msql@chaos test]$
If I'm not mistaken, after a bus error the program counter is usually
left pointing at the next instruction, so it's probably not the return,
but the assignment of the timeout_value field in the Connection object
that triggered the bus error. What is baffling me is why? The object
is not null (this=0x4000), nor does it seem to be misaligned, so why
the bus error? Anyone have any ideas on this? My guess would be a bug
in the code generation. Can you try different compiler options, especially
different optimization levels, or no optimization, or even a different
compiler version?
--
Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil
Dept. Physiology, U. of Manitoba Phone: (204)789-3766
Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930
_______________________________________________
htdig-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/htdig-dev
