Yeah, we do this for apps here, add a signal handler on crashes to fork gdb off as a subprocess which then attaches to the parent process and then does a backtrace.
We do this for crash reports for users and if it's a developer it stays in gdb and doesn't exit so we can debug it right there. We also do this because we use a big amount of memory (circuit analysis data for microprocessors) and producing a core file is not practical for disk size issues. Alan On Fri, 25 Feb 2005 09:00:58 -0500, aaron <[EMAIL PROTECTED]> wrote: > On Fri, 25 Feb 2005 14:05:45 +0100, Thomas B�rkel <[EMAIL PROTECTED]> wrote: > > When aMule crashes, it automatically spits out a backtrace into the console. > > > > I wonder, if this could be implemented in myth, too? I guess, this will > > cost some performance, but if it would be only a few percent, maybe it > > would be worth it. > > This is something I've thought about as well. It shouldn't have any > performance impact because the stack walk only needs to occur when the > crash occurs (ie/ when the signal is delivered). I think there are > even function(s) in glibc to get the stack (although perhaps they > don't work if all the symbols are stripped? I have no idea). > > One thing I hadn't looked into is whether the glibc functions work > properly with threads. > > My real job is a doing defect support for a large commercial > application, and this sort of diagnostic information is invaluable to > us. Especially for the case where problems aren't reproducible. > > -- > aaron > _______________________________________________ > mythtv-dev mailing list > [email protected] > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev > _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
