Ulrich Drepper <drepper(a)cygnus.com> writes:
SL Baur <steve(a)xemacs.org> writes:
> I don't know about that. There used to be code in XEmacs to
> self-generate a C stack backtrace in Solaris. I took it out because
> it had a tendency to crash in the middle of printing the backtrace.
The code I have in glibc does not have this problem. There are three
functions:
backtrace() to get the values
backtrace_symbols() to convert it into symbols
or
backtrace_symbols_fd() to immediately write the result to
an file descriptor
I would say that seeing these functions crashing is highly unlikely
unless the memory the libc uses gets clobbered. It is not a simple
minded implementation.
But does it work? :) I thought this would be nifty to use in our server,
and I just tried it. I just threw in this code in the midst of it
processing a connection:
{
void *array[250];
int n = backtrace(array,250);
backtrace_symbols_fd(array,n,fileno(stderr));
}
All I got was:
[0x805d3f7]
[0x805c21e]
[0x805c994]
[0x805c9fc]
[0x805b40a]
/lib/libc.so.6(__libc_start_main+0xeb)[0x401cfcb3]
[0x8051ab1]
This is with debugging server, and according to file:
/usr/local/aventail/bin/socks5: ELF 32-bit LSB executable, Intel 80386, version 1,
dynamically linked (uses shared libs), not stripped
This is on linux (RH 6.0 based install) and glibc 2.1.1. Any clue what
could be causing it not to find the symbols?
-Bill P.