Published 2007-01-31 17:41:05

One the projects I'm working on is a SyncML server, written from scratch in D, It's currently in testing mode, and we found that the server was mysteriously crashing. Unfortunatly, since it's threaded, and forked as a daemon, we didn't really want to run it under GDB, (and since GDB segfaults on startup anyway). we where at a bit of a quagmire about how to find the bug.

So after a bit of searching through I came across the idea of catching the SIGSEGV signal and calling backtrace and backtrace_symbols

This little trick can product output that looks something like
/path/to/application [0xAAAAAA] << address of code
/path/to/application [0xAAAAAA] << address of code
/path/to/application [0xAAAAAA] << address of code
/path/to/application [0xAAAAAA] << address of code
which initially seemed a bit cryptic, but by putting it together with
addr2line can result in some great debugging information.

This is my little backtrace logger for the deamon logger.
static void print_trace()

void *btarray[10];
size_t size;
char **strings;
size_t i;
pid_t pid = getpid();

size = backtrace(cast(void**)btarray, 10);
strings = backtrace_symbols(cast(void**)btarray, size);

std.process.system("/bin/echo '----BACKTRACE------' " ~
"> /var/log/myproject/backtrace.log");

for(i = 0; i < size; i++) {

char[] line = std.string.toString(strings[i]);
char[][] bits = std.string.split(line, "[");
char[] left = std.string.strip(bits[0]);
if (!left.length) {
// skip lines with ( in them...
if (std.string.find(left,"(") > -1) {

char[] addr = bits[1][2..length-1];

std.process.system("/bin/echo '----" ~ addr
~ "------' >> /var/log/myproject/backtrace.log");
std.process.system("/usr/bin/addr2line -f -e " ~
left ~ " " ~ addr ~ " >> /var/log/myproject/myproject.log");


of course you need to use a few C externs to make this work:
extern (C) {
int backtrace(void **__array, int __size);
char** backtrace_symbols(void **__array, int __size);
pid_t getpid();
sighandler_t signal(int signum, sighandler_t handler);
void sigsegv(int sig)
// reset the handler.
signal(SIGSEGV, cast(sighandler_t) 0);
// really die


and to add it to you application, stick this in main() somewhere
signal(SIGSEGV, &sigsegv);
testing it is quite simple, just do this in D

void  testSegfault()

class SegTest {
void test() {}
SegTest a;
Now looking at the debug file, you can work out where it failed...
----805e971------ (THIS IS MY OUTPUT CODE)

I'm sure with some more work, you could get it to log to syslog...
Mentioned By: : april (86 referals) : php daemon (39 referals) : january (34 referals) : catch SIGSEGV (32 referals) : december (28 referals) : backtrace_symbols addr2line (22 referals) : Planet PHP (18 referals) : addr2line backtrace_symbols (16 referals) : catching SIGSEGV (6 referals) : backtrace_symbols (5 referals) : Backtracing php (5 referals) : sigsegv catch (4 referals) : Debian HK : Debian @ Hong Kong (3 referals) : backtracing (3 referals) : execinfo.h (3 referals) : feed deamon (3 referals) : php daemon (3 referals) : php segfault (3 referals) : sigsegv string::find (3 referals) : std.process (3 referals)


Say no to SIGSEGV
I am wary of code that attempts to catch SIGSEGV and do something meaningful with it. When you are in a SEGV state, you could be there because of a corrupted stack or all kinds of other bad things. Running further non-trivial code (and from the looks of your handler it is non-trivial) is likely to trigger
another SEGV in which case your handler is called again and you get
another SEGV.

If your memory is corrupt, trying to do printf() which does complicated
things like malloc() is likely going to dereference an invalid pointer,
so you end up with a second coredump.

Much better to let the process die a natural death. Once it has dumped core, you can have a separate process that converts the core to a stacktrace. If your GDB is segfaulting on startup, I'd suggest spending more time investigating why that is instead of trying to catch fatal signals, which are fatal for a reason.
#0 - Andrei ( Link) on 2007-02-01 00:46:25 Delete Comment
D may be different
While dealing with PHP, segfaults have come from all over the place, and this solution would probably mess up as you describe.

For the time being though, The only reason I've ever seen my D code segfault is on null pointer calls (which are unfortunatly not assert tested yet. - although that's apparently on the todo list.) So, It's not so much of a concern about stack corruption.

That said I could do with working out why gdb segfaults.. It would make life easier.
#1 - Alan Knowles ( Link) on 2007-02-01 08:00:23 Delete Comment

Add Your Comment

Follow us on