[mythtv] Automatic backtrace on crash (crashhandler)?

Alan Gonzalez alandgonzalez at gmail.com
Fri Feb 25 17:16:04 UTC 2005


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 <memoryguy at gmail.com> wrote:
> On Fri, 25 Feb 2005 14:05:45 +0100, Thomas Börkel <thomas at boerkel.de> 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
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>


More information about the mythtv-dev mailing list