Re: Stack backtrace on fatal error?

From: Tim Tyler (tim_at_tt1lock.org)
Date: 09/20/04 

Date: Mon, 20 Sep 2004 21:06:35 GMT

R. Rajesh Jeba Anbiah <ng4rrjanbiah@rediffmail.com> wrote or quoted:
> Tim Tyler <tim@tt1lock.org> wrote in message news:<I48AK9.A06@bath.ac.uk>...

> > Unfortunately, calling debug_backtrace() within the fatal error handler
> > seems to produce one function call - to the fatal error handler itself -
> > so this approach does not seem effective at getting hold of backtrace
> > information for the fatal error - and getting hold of that information
> > was the main reason I was interested in trapping the error in the first
> > place.
>
> For me, it is working (4.3.4).

Hmm. I may try again someday.

It's a "dreadful hack" - but it /would/ be helpful if I could get it to work. 

-- 
__________
 |im |yler  http://timtyler.org/  tim@tt1lock.org  Remove lock to reply.

Relevant Pages

  • Re: xconfig segfault
    ... On Mon, 20 Nov 2006, Randy Dunlap wrote: ... backtrace. ... Hmm, an uninitialize field is IMO the only thing that could go wrong here. ... More majordomo info at http://vger.kernel.org/majordomo-info.html ...
    (Linux-Kernel)
  • Re: Flexible __autoload scheme
    ... R. Rajesh Jeba Anbiah wrote: ... > Hmm... ... I guess, you're duplicating the code. ... When you invoke, ...
    (comp.lang.php)
  • Re: vinum lock panic at startup -current
    ... >> What was the actual panic message? ... Hmm. ... This is a very different backtrace from the last one you showed me. ... See complete headers for address and phone numbers ...
    (freebsd-current)
  • Re: OT: gmail invites
    ... R. Rajesh Jeba Anbiah wrote: ... FCFS ... Hmm.. ... your mailbox is already full;) ...
    (comp.lang.php)