I had a look at the do_coredump stuff and it looks like it could be
altered to call gdb in the same way that
modprobe gets called by kmod... however I don't sufficiently know the
code to work out whether it'd work properly
or not.
A patch to glibc would perhaps be better, but I know that code even
less!
Something like responding to SIGTRAP would probably be ideal.
Tony
--
"Two weeks before due date, the programmers work 22 hour days cobbling an
application from... (apparently) one programmer bashing his face into the
keyboard." -- Dilbert
t...@magenta-netlogic.com http://www.nothing-on.tv
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Yes, I use that to get a symbolic stack dump after a crash,
although I find that the gdb so invoked doesn't accept interactive
commands, and I have to use 'kill -9' afterwards.
Here's the code I use:
void dump_stack(int signum)
{
(void) signum;
char s[160];
// The right command to execute depends on the program. Adjust to taste.
system("echo 'info threads\nbt\nthread 3\nbt\nthread 4\nbt\nthread 5\nbt\n' > gdbcmd");
sprintf(s, "gdb -batch -x gdbcmd %s %d", argv0, (int) getpid());
printf("Crashed! Starting debugger to get stack dump. You may need to kill -9 this process afterwards.\n");
system(s);
exit(1);
}
main() {
signal(SIGSEGV, dump_stack);
signal(SIGBUS, dump_stack);
...
Just check the code I sent, it works fine for Your needs.
- Davide
Because the program is invoked as part of a much larger system & I don't
know which process is going to crash when.
Having gdb come up automatically would greatly decrease development
time. I'm trying to track down multiple bugs (caused by me, but they
still need tracking down) which show up during stress testing. The bug
will manifest itself in maybe the 1000th iteration... If I could hack
gdb into coming up automatically when things went wrong it'd get rid of
the need to have thousands of printf's in the app (which is my primary
debugging tool at the moment).
At work I do this all the time... Windows pops up a dialog which
basically says 'the program has crashed, debug?' and drops you straight
into VC with everything intact. It has assertion macros which wrap int3
instructions. You then continue your app under normal debug conditions.
Tony
(Fighting with evolution because Mozilla broke imap again... sigh...)
--
"Two weeks before due date, the programmers work 22 hour days cobbling an
application from... (apparently) one programmer bashing his face into the
keyboard." -- Dilbert
t...@magenta-netlogic.com http://www.nothing-on.tv
-