Symbolic tracebacks on Debian
in [ADA]
|
From: Dmitry A. Kazakov on 22 May 2010 09:56 On Sat, 22 May 2010 15:20:34 +0200, Bj�rn Persson wrote: > Stephen Leake wrote: > >> I dump the stack trace as hex addresses, then later run addr2line >> manually if I want the symbolic trace. > > That's what I'm doing and it's not helping. I'm trying to find out why my > email doorkeeper daemon sometimes crashes. I write the addresses to the log, > but when I pass them to addr2line it resolves ony those that are in my own > code. The crashes seem to happen somewhere in one of the libraries I use, > and addr2line returns only question marks for those addresses. I don't know > why. Perhaps it doesn't understand separate debug information files? That is the biggest problem when dealing with Gtk. This is why I integrated symbolic traceback into the GtkAda contributions + trapping of all log events of the Gtk. When Gtk logs an event (error, warning), I trace the stack at once. At this point it is still traceable. C stuff is shown as ???, but the Ada's caller's chain is OK. If you let it go further, it would crash in 80% cases, and the addresses will be guaranteed rubbish at that point. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: (see below) on 22 May 2010 17:37 On 22/05/2010 12:25, in article m2aarsuqis.fsf(a)pushface.org, "Simon Wright" <simon(a)pushface.org> wrote: > "(see below)" <yaldnif.w(a)blueyonder.co.uk> writes: > >> Can you say exactly what the steps are to do that? >> I've never understood it + therefore never used it. > > You need to call > > GNAT.Exception_Traces.Trace_On > (Kind => GNAT.Exception_Traces.Unhandled_Raise); > > from somewhere in your program and run gnatmake with -bargs -E. Many thanks. -- Bill Findlay <surname><forename> chez blueyonder.co.uk
From: Stephen Leake on 23 May 2010 09:28 Simon Wright <simon(a)pushface.org> writes: > "(see below)" <yaldnif.w(a)blueyonder.co.uk> writes: > >> On 21/05/2010 09:52, in article 82bpc8s17m.fsf(a)stephe-leake.org, "Stephen >> Leake" <stephen_leake(a)stephe-leake.org> wrote: > >>> Because symbolic traceback are not supported on _all_ gnat platforms, I >>> don't use them on _any_ - that way my code is portable. So I did not >>> notice this problem. >>> >>> I dump the stack trace as hex addresses, then later run addr2line >>> manually if I want the symbolic trace. >> >> Can you say exactly what the steps are to do that? >> I've never understood it + therefore never used it. > > You need to call > > GNAT.Exception_Traces.Trace_On > (Kind => GNAT.Exception_Traces.Unhandled_Raise); I never do this. > from somewhere in your program and run gnatmake with -bargs -E. I only do this if I want symbolic traces from the running program, which I don't anymore. -- -- Stephe
From: Simon Wright on 23 May 2010 11:52 Stephen Leake <stephen_leake(a)stephe-leake.org> writes: > Simon Wright <simon(a)pushface.org> writes: > >> "(see below)" <yaldnif.w(a)blueyonder.co.uk> writes: >> >>> On 21/05/2010 09:52, in article 82bpc8s17m.fsf(a)stephe-leake.org, "Stephen >>> Leake" <stephen_leake(a)stephe-leake.org> wrote: >> >>>> Because symbolic traceback are not supported on _all_ gnat platforms, I >>>> don't use them on _any_ - that way my code is portable. So I did not >>>> notice this problem. >>>> >>>> I dump the stack trace as hex addresses, then later run addr2line >>>> manually if I want the symbolic trace. >>> >>> Can you say exactly what the steps are to do that? >>> I've never understood it + therefore never used it. >> >> You need to call >> >> GNAT.Exception_Traces.Trace_On >> (Kind => GNAT.Exception_Traces.Unhandled_Raise); > > I never do this. > >> from somewhere in your program and run gnatmake with -bargs -E. > > I only do this if I want symbolic traces from the running program, which > I don't anymore. If you want _symbolic_ traces you add GNAT.Exception_Traces.Set_Trace_Decorator (Decorator => GNAT.Traceback.Symbolic.Symbolic_Traceback'Access); Actually, there is a difference: this code with GNAT.Exception_Traces; procedure T is Foo, Bar : exception; task T is entry Start; end T; task body T is begin accept Start; raise Bar; end T; begin GNAT.Exception_Traces.Trace_On (Kind => GNAT.Exception_Traces.Unhandled_Raise); T.Start; raise Foo; end T; results in $ ./t Unhandled Exception raised Exception name: T.FOO Message: t.adb:16 Call stack traceback locations: 0x100001577 0x10000141b task t_0000000100800E00 terminated by unhandled exception Exception name: T.BAR Message: t.adb:10 Call stack traceback locations: 0x100001742 0x10000aa82 0x7fff825fb8b4 whereas with the Trace_On call commented out, it generates $ ./t Execution terminated by unhandled exception Exception name: T.FOO Message: t.adb:16 Call stack traceback locations: 0x10000157d 0x10000142b so you get to see the unhandled exceptions in tasks too.
From: (see below) on 23 May 2010 14:35 On 23/05/2010 16:52, in article m2632evcn3.fsf(a)pushface.org, "Simon Wright" <simon(a)pushface.org> wrote: > Stephen Leake <stephen_leake(a)stephe-leake.org> writes: > >> Simon Wright <simon(a)pushface.org> writes: >>> You need to call >>> >>> GNAT.Exception_Traces.Trace_On >>> (Kind => GNAT.Exception_Traces.Unhandled_Raise); >> >> I never do this. >> >>> from somewhere in your program and run gnatmake with -bargs -E. >> >> I only do this if I want symbolic traces from the running program, which >> I don't anymore. > > If you want _symbolic_ traces you add > > GNAT.Exception_Traces.Set_Trace_Decorator > (Decorator => GNAT.Traceback.Symbolic.Symbolic_Traceback'Access); > > Actually, there is a difference: this code > > with GNAT.Exception_Traces; > procedure T is > Foo, Bar : exception; > task T is > entry Start; > end T; > task body T is > begin > accept Start; > raise Bar; > end T; > begin > GNAT.Exception_Traces.Trace_On > (Kind => GNAT.Exception_Traces.Unhandled_Raise); > T.Start; > raise Foo; > end T; > > results in > > $ ./t > > Unhandled Exception raised > Exception name: T.FOO > Message: t.adb:16 > Call stack traceback locations: > 0x100001577 0x10000141b > task t_0000000100800E00 terminated by unhandled exception > Exception name: T.BAR > Message: t.adb:10 > Call stack traceback locations: > 0x100001742 0x10000aa82 0x7fff825fb8b4 > > whereas with the Trace_On call commented out, it generates > > $ ./t > > Execution terminated by unhandled exception > Exception name: T.FOO > Message: t.adb:16 > Call stack traceback locations: > 0x10000157d 0x10000142b > > so you get to see the unhandled exceptions in tasks too. Are these features enabled in your OS X port, Simon? -- Bill Findlay <surname><forename> chez blueyonder.co.uk
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: Ada Debian policy plea Next: info version of Ada reference manuals |