From: Stephen Leake on
Ludovic Brenta <ludovic(a)ludovic-brenta.org> writes:

> On the other hand,
> since nobody noticed or reported this problem before you and gnat-4.3
> has been in Debian since 2008-01-30, I'm starting to wonder whether
> symbolic tracebacks are all that useful.

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.

--
-- Stephe
From: (see below) on
On 21/05/2010 09:52, in article 82bpc8s17m.fsf(a)stephe-leake.org, "Stephen
Leake" <stephen_leake(a)stephe-leake.org> wrote:

> Ludovic Brenta <ludovic(a)ludovic-brenta.org> writes:
>
>> On the other hand,
>> since nobody noticed or reported this problem before you and gnat-4.3
>> has been in Debian since 2008-01-30, I'm starting to wonder whether
>> symbolic tracebacks are all that useful.
>
> 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.

--
Bill Findlay
<surname><forename> chez blueyonder.co.uk


From: Simon Wright on
"(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);

from somewhere in your program and run gnatmake with -bargs -E.
From: Yannick Duchêne (Hibou57) on
Le Sat, 22 May 2010 13:03:20 +0200, (see below)
<yaldnif.w(a)blueyonder.co.uk> a écrit:
>> 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.
If you use GPS or don't bother to use when it is needed, here is one tool
which may help:
http://www.les-ziboux.rasama.org/addr2line2locations-tool-ada-gps-en.html
Comments welcome.

--
There is even better than a pragma Assert: a SPARK --# check.
From: Björn Persson on
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?

--
Björn Persson
PGP key A88682FD