* Re: Symbolic tracebacks on Debian (Was: About static libraries and Debian policy)
2010-05-20 7:20 ` Symbolic tracebacks on Debian (Was: About static libraries and Debian policy) Ludovic Brenta
@ 2010-05-20 8:38 ` Alex R. Mosteo
2010-05-21 12:26 ` Ludovic Brenta
2010-05-20 14:04 ` Symbolic tracebacks on Debian (Was: About static libraries and Debian policy) Dmitry A. Kazakov
` (2 subsequent siblings)
3 siblings, 1 reply; 37+ messages in thread
From: Alex R. Mosteo @ 2010-05-20 8:38 UTC (permalink / raw)
Ludovic Brenta wrote:
> Björn Persson writes on comp.lang.ada:
>> Ludovic Brenta wrote:
>(...)
>
> On the one hand, this is quite embarrassing as it means that both
> gnat-4.3 and gnat-4.4 are broken in this respect. 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.
I'm not user of the debian packages, but I would be quite lost without full
stack backtraces.
Alex.
>
> Nevertheless, this deserves a bug in the Debian bug tracking system and
> a fix before the release of Squeeze. Thanks for reporting!
>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian (Was: About static libraries and Debian policy)
2010-05-20 8:38 ` Alex R. Mosteo
@ 2010-05-21 12:26 ` Ludovic Brenta
2010-05-25 8:39 ` Symbolic tracebacks on Debian Ludovic Brenta
0 siblings, 1 reply; 37+ messages in thread
From: Ludovic Brenta @ 2010-05-21 12:26 UTC (permalink / raw)
Alex R. Mosteo wrote on comp.lang.ada:
> Ludovic Brenta wrote:
> > Björn Persson writes on comp.lang.ada:
> >> Ludovic Brenta wrote:
> >(...)
>
> > On the one hand, this is quite embarrassing as it means that both
> > gnat-4.3 and gnat-4.4 are broken in this respect. 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.
>
> I'm not user of the debian packages, but I would be quite lost without full
> stack backtraces.
>
> Alex.
>
>> Nevertheless, this deserves a bug in the Debian bug tracking system and
>> a fix before the release of Squeeze. Thanks for reporting!
I filed a bug report and am testing a fix; I'll probably upload it on
Tuesday or Wednesday. See http://bugs.debian.org/582452 and followup
there if you want.
--
Ludovic Brenta.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian
2010-05-21 12:26 ` Ludovic Brenta
@ 2010-05-25 8:39 ` Ludovic Brenta
0 siblings, 0 replies; 37+ messages in thread
From: Ludovic Brenta @ 2010-05-25 8:39 UTC (permalink / raw)
I wrote on comp.lang.ada:
> I filed a bug report and am testing a fix; I'll probably upload it on
> Tuesday or Wednesday. Seehttp://bugs.debian.org/582452 and followup
> there if you want.
The fix is now available in Debian unstable as part of gnat-4.4 (=
4.4.4-4)
on most architectures. It should migrate to testing in 10 days.
--
Ludovic Brenta.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian (Was: About static libraries and Debian policy)
2010-05-20 7:20 ` Symbolic tracebacks on Debian (Was: About static libraries and Debian policy) Ludovic Brenta
2010-05-20 8:38 ` Alex R. Mosteo
@ 2010-05-20 14:04 ` Dmitry A. Kazakov
2010-05-21 8:52 ` Symbolic tracebacks on Debian Stephen Leake
2010-05-22 12:53 ` Symbolic tracebacks on Debian (Was: About static libraries and Debian policy) Björn Persson
3 siblings, 0 replies; 37+ messages in thread
From: Dmitry A. Kazakov @ 2010-05-20 14:04 UTC (permalink / raw)
On Thu, 20 May 2010 09:20:25 +0200, Ludovic Brenta wrote:
> 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.
Symbolic traceback is an integral part of GtkAda contributions. Its trace
window can dump, decode, navigate symbolic traceback. It is essential when
debugging GtkAda programs.
(I didn't use Debian until recent time)
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian
2010-05-20 7:20 ` Symbolic tracebacks on Debian (Was: About static libraries and Debian policy) Ludovic Brenta
2010-05-20 8:38 ` Alex R. Mosteo
2010-05-20 14:04 ` Symbolic tracebacks on Debian (Was: About static libraries and Debian policy) Dmitry A. Kazakov
@ 2010-05-21 8:52 ` Stephen Leake
2010-05-22 11:03 ` (see below)
2010-05-22 13:20 ` Björn Persson
2010-05-22 12:53 ` Symbolic tracebacks on Debian (Was: About static libraries and Debian policy) Björn Persson
3 siblings, 2 replies; 37+ messages in thread
From: Stephen Leake @ 2010-05-21 8:52 UTC (permalink / raw)
Ludovic Brenta <ludovic@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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian
2010-05-21 8:52 ` Symbolic tracebacks on Debian Stephen Leake
@ 2010-05-22 11:03 ` (see below)
2010-05-22 11:25 ` Simon Wright
2010-05-22 11:30 ` Yannick Duchêne (Hibou57)
2010-05-22 13:20 ` Björn Persson
1 sibling, 2 replies; 37+ messages in thread
From: (see below) @ 2010-05-22 11:03 UTC (permalink / raw)
On 21/05/2010 09:52, in article 82bpc8s17m.fsf@stephe-leake.org, "Stephen
Leake" <stephen_leake@stephe-leake.org> wrote:
> Ludovic Brenta <ludovic@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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian
2010-05-22 11:03 ` (see below)
@ 2010-05-22 11:25 ` Simon Wright
2010-05-22 21:37 ` (see below)
2010-05-23 13:28 ` Stephen Leake
2010-05-22 11:30 ` Yannick Duchêne (Hibou57)
1 sibling, 2 replies; 37+ messages in thread
From: Simon Wright @ 2010-05-22 11:25 UTC (permalink / raw)
"(see below)" <yaldnif.w@blueyonder.co.uk> writes:
> On 21/05/2010 09:52, in article 82bpc8s17m.fsf@stephe-leake.org, "Stephen
> Leake" <stephen_leake@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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian
2010-05-22 11:25 ` Simon Wright
@ 2010-05-22 21:37 ` (see below)
2010-05-23 13:28 ` Stephen Leake
1 sibling, 0 replies; 37+ messages in thread
From: (see below) @ 2010-05-22 21:37 UTC (permalink / raw)
On 22/05/2010 12:25, in article m2aarsuqis.fsf@pushface.org, "Simon Wright"
<simon@pushface.org> wrote:
> "(see below)" <yaldnif.w@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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian
2010-05-22 11:25 ` Simon Wright
2010-05-22 21:37 ` (see below)
@ 2010-05-23 13:28 ` Stephen Leake
2010-05-23 15:52 ` Simon Wright
2010-05-24 9:03 ` Stephen Leake
1 sibling, 2 replies; 37+ messages in thread
From: Stephen Leake @ 2010-05-23 13:28 UTC (permalink / raw)
Simon Wright <simon@pushface.org> writes:
> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>
>> On 21/05/2010 09:52, in article 82bpc8s17m.fsf@stephe-leake.org, "Stephen
>> Leake" <stephen_leake@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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian
2010-05-23 13:28 ` Stephen Leake
@ 2010-05-23 15:52 ` Simon Wright
2010-05-23 18:35 ` (see below)
2010-05-24 9:03 ` Stephen Leake
1 sibling, 1 reply; 37+ messages in thread
From: Simon Wright @ 2010-05-23 15:52 UTC (permalink / raw)
Stephen Leake <stephen_leake@stephe-leake.org> writes:
> Simon Wright <simon@pushface.org> writes:
>
>> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>>
>>> On 21/05/2010 09:52, in article 82bpc8s17m.fsf@stephe-leake.org, "Stephen
>>> Leake" <stephen_leake@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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian
2010-05-23 15:52 ` Simon Wright
@ 2010-05-23 18:35 ` (see below)
2010-05-23 19:46 ` Simon Wright
0 siblings, 1 reply; 37+ messages in thread
From: (see below) @ 2010-05-23 18:35 UTC (permalink / raw)
On 23/05/2010 16:52, in article m2632evcn3.fsf@pushface.org, "Simon Wright"
<simon@pushface.org> wrote:
> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> Simon Wright <simon@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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian
2010-05-23 18:35 ` (see below)
@ 2010-05-23 19:46 ` Simon Wright
2010-05-24 9:04 ` Stephen Leake
0 siblings, 1 reply; 37+ messages in thread
From: Simon Wright @ 2010-05-23 19:46 UTC (permalink / raw)
"(see below)" <yaldnif.w@blueyonder.co.uk> writes:
> Are these features enabled in your OS X port, Simon?
That was a prerelease 4.5.0 -- presently running with my build of the
official GCC release.
So far as I know, these features are the same.. yes, just tried it.
The tracebacks you get with atos are rather opaque, and the tool is too
stupid to work out the architecture for itself ..
$ atos -o t -arch x86_64 0x100001577 0x10000141b
_ada_t (in t) (t.adb:16)
main (in t) (b~t.adb:196)
$ atos -o t -arch x86_64 0x100001742 0x10000aa82 0x7fff825fb8b4
t__tTKB.2815 (in t) + 86
system__tasking__stages__task_wrapper (in t) + 418
0x7fff825fb8b4
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian
2010-05-23 19:46 ` Simon Wright
@ 2010-05-24 9:04 ` Stephen Leake
2010-05-24 19:14 ` Simon Wright
0 siblings, 1 reply; 37+ messages in thread
From: Stephen Leake @ 2010-05-24 9:04 UTC (permalink / raw)
Simon Wright <simon@pushface.org> writes:
> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>
>> Are these features enabled in your OS X port, Simon?
>
> That was a prerelease 4.5.0 -- presently running with my build of the
> official GCC release.
>
> So far as I know, these features are the same.. yes, just tried it.
>
> The tracebacks you get with atos are rather opaque, and the tool is too
> stupid to work out the architecture for itself ..
>
> $ atos -o t -arch x86_64 0x100001577 0x10000141b
> _ada_t (in t) (t.adb:16)
> main (in t) (b~t.adb:196)
Good enough for emacs to find and display the source location, which is
all you really need.
--
-- Stephe
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian
2010-05-24 9:04 ` Stephen Leake
@ 2010-05-24 19:14 ` Simon Wright
2010-05-25 2:13 ` Stephen Leake
0 siblings, 1 reply; 37+ messages in thread
From: Simon Wright @ 2010-05-24 19:14 UTC (permalink / raw)
Stephen Leake <stephen_leake@stephe-leake.org> writes:
> Simon Wright <simon@pushface.org> writes:
>
>> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>>
>>> Are these features enabled in your OS X port, Simon?
>>
>> That was a prerelease 4.5.0 -- presently running with my build of the
>> official GCC release.
>>
>> So far as I know, these features are the same.. yes, just tried it.
>>
>> The tracebacks you get with atos are rather opaque, and the tool is too
>> stupid to work out the architecture for itself ..
>>
>> $ atos -o t -arch x86_64 0x100001577 0x10000141b
>> _ada_t (in t) (t.adb:16)
>> main (in t) (b~t.adb:196)
>
> Good enough for emacs to find and display the source location, which is
> all you really need.
I agree about that one, but the next (from the task which died with an
unhandled exception) was
$ atos -o t -arch x86_64 0x100001742 0x10000aa82 0x7fff825fb8b4
t__tTKB.2815 (in t) + 86
system__tasking__stages__task_wrapper (in t) + 418
0x7fff825fb8b4
I dare say a less trivia example would work better.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian
2010-05-24 19:14 ` Simon Wright
@ 2010-05-25 2:13 ` Stephen Leake
2010-05-25 9:02 ` Alex R. Mosteo
2010-05-25 19:16 ` Simon Wright
0 siblings, 2 replies; 37+ messages in thread
From: Stephen Leake @ 2010-05-25 2:13 UTC (permalink / raw)
Simon Wright <simon@pushface.org> writes:
> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> Simon Wright <simon@pushface.org> writes:
>>
>>> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>>>
>>>> Are these features enabled in your OS X port, Simon?
>>>
>>> That was a prerelease 4.5.0 -- presently running with my build of the
>>> official GCC release.
>>>
>>> So far as I know, these features are the same.. yes, just tried it.
>>>
>>> The tracebacks you get with atos are rather opaque, and the tool is too
>>> stupid to work out the architecture for itself ..
>>>
>>> $ atos -o t -arch x86_64 0x100001577 0x10000141b
>>> _ada_t (in t) (t.adb:16)
>>> main (in t) (b~t.adb:196)
>>
>> Good enough for emacs to find and display the source location, which is
>> all you really need.
>
> I agree about that one, but the next (from the task which died with an
> unhandled exception) was
>
> $ atos -o t -arch x86_64 0x100001742 0x10000aa82 0x7fff825fb8b4
> t__tTKB.2815 (in t) + 86
> system__tasking__stages__task_wrapper (in t) + 418
> 0x7fff825fb8b4
>
> I dare say a less trivia example would work better.
I often find the stack trace from a multitasking program to be pretty
useless. The real problem is in some inner task, but the stack trace you
get is from the environment task.
That's when you have to write code to have each task dump its own stack
when it dies.
And on the gripping hand, stack traces from fully optimized code are
also often useless.
--
-- Stephe
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian
2010-05-25 2:13 ` Stephen Leake
@ 2010-05-25 9:02 ` Alex R. Mosteo
2010-05-25 19:16 ` Simon Wright
1 sibling, 0 replies; 37+ messages in thread
From: Alex R. Mosteo @ 2010-05-25 9:02 UTC (permalink / raw)
Stephen Leake wrote:
> Simon Wright <simon@pushface.org> writes:
>
>> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>>
>>> Simon Wright <simon@pushface.org> writes:
>>>
>>>> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>>>>
>>>>> Are these features enabled in your OS X port, Simon?
>>>>
>>>> That was a prerelease 4.5.0 -- presently running with my build of the
>>>> official GCC release.
>>>>
>>>> So far as I know, these features are the same.. yes, just tried it.
>>>>
>>>> The tracebacks you get with atos are rather opaque, and the tool is too
>>>> stupid to work out the architecture for itself ..
>>>>
>>>> $ atos -o t -arch x86_64 0x100001577 0x10000141b
>>>> _ada_t (in t) (t.adb:16)
>>>> main (in t) (b~t.adb:196)
>>>
>>> Good enough for emacs to find and display the source location, which is
>>> all you really need.
>>
>> I agree about that one, but the next (from the task which died with an
>> unhandled exception) was
>>
>> $ atos -o t -arch x86_64 0x100001742 0x10000aa82 0x7fff825fb8b4
>> t__tTKB.2815 (in t) + 86
>> system__tasking__stages__task_wrapper (in t) + 418
>> 0x7fff825fb8b4
>>
>> I dare say a less trivia example would work better.
>
> I often find the stack trace from a multitasking program to be pretty
> useless. The real problem is in some inner task, but the stack trace you
> get is from the environment task.
This is not my experience. I routinely work with multitasking programs and I
usually get the full backtrace of the task that has caused the exception.
Perhaps the architecture has something to do? I use regular x86 linux.
> That's when you have to write code to have each task dump its own stack
> when it dies.
>
> And on the gripping hand, stack traces from fully optimized code are
> also often useless.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian
2010-05-25 2:13 ` Stephen Leake
2010-05-25 9:02 ` Alex R. Mosteo
@ 2010-05-25 19:16 ` Simon Wright
2010-05-26 7:30 ` Stephen Leake
1 sibling, 1 reply; 37+ messages in thread
From: Simon Wright @ 2010-05-25 19:16 UTC (permalink / raw)
Stephen Leake <stephen_leake@stephe-leake.org> writes:
> I often find the stack trace from a multitasking program to be pretty
> useless. The real problem is in some inner task, but the stack trace
> you get is from the environment task.
>
> That's when you have to write code to have each task dump its own
> stack when it dies.
Unless you add (as I said above)
GNAT.Exception_Traces.Trace_On
(Kind => GNAT.Exception_Traces.Unhandled_Raise);
I think this may not work as advertised (or, possibly more annoying, may
be unreliable) on older GNATs.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian
2010-05-25 19:16 ` Simon Wright
@ 2010-05-26 7:30 ` Stephen Leake
0 siblings, 0 replies; 37+ messages in thread
From: Stephen Leake @ 2010-05-26 7:30 UTC (permalink / raw)
Simon Wright <simon@pushface.org> writes:
> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> I often find the stack trace from a multitasking program to be pretty
>> useless. The real problem is in some inner task, but the stack trace
>> you get is from the environment task.
>>
>> That's when you have to write code to have each task dump its own
>> stack when it dies.
>
> Unless you add (as I said above)
>
> GNAT.Exception_Traces.Trace_On
> (Kind => GNAT.Exception_Traces.Unhandled_Raise);
>
> I think this may not work as advertised (or, possibly more annoying, may
> be unreliable) on older GNATs.
The description of that feature makes no mention of tasking. I'll have
to try it.
--
-- Stephe
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian
2010-05-23 13:28 ` Stephen Leake
2010-05-23 15:52 ` Simon Wright
@ 2010-05-24 9:03 ` Stephen Leake
1 sibling, 0 replies; 37+ messages in thread
From: Stephen Leake @ 2010-05-24 9:03 UTC (permalink / raw)
Stephen Leake <stephen_leake@stephe-leake.org> writes:
> Simon Wright <simon@pushface.org> writes:
>
>> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>>
>>> On 21/05/2010 09:52, in article 82bpc8s17m.fsf@stephe-leake.org, "Stephen
>>> Leake" <stephen_leake@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.
Sorry, I was mistaken; -bars -E is required for numeric tracebacks. It's
been too long since I looked at the contents of my standard gpr file.
--
-- Stephe
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian
2010-05-22 11:03 ` (see below)
2010-05-22 11:25 ` Simon Wright
@ 2010-05-22 11:30 ` Yannick Duchêne (Hibou57)
1 sibling, 0 replies; 37+ messages in thread
From: Yannick Duchêne (Hibou57) @ 2010-05-22 11:30 UTC (permalink / raw)
Le Sat, 22 May 2010 13:03:20 +0200, (see below)
<yaldnif.w@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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian
2010-05-21 8:52 ` Symbolic tracebacks on Debian Stephen Leake
2010-05-22 11:03 ` (see below)
@ 2010-05-22 13:20 ` Björn Persson
2010-05-22 13:56 ` Dmitry A. Kazakov
1 sibling, 1 reply; 37+ messages in thread
From: Björn Persson @ 2010-05-22 13:20 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian
2010-05-22 13:20 ` Björn Persson
@ 2010-05-22 13:56 ` Dmitry A. Kazakov
0 siblings, 0 replies; 37+ messages in thread
From: Dmitry A. Kazakov @ 2010-05-22 13:56 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Symbolic tracebacks on Debian (Was: About static libraries and Debian policy)
2010-05-20 7:20 ` Symbolic tracebacks on Debian (Was: About static libraries and Debian policy) Ludovic Brenta
` (2 preceding siblings ...)
2010-05-21 8:52 ` Symbolic tracebacks on Debian Stephen Leake
@ 2010-05-22 12:53 ` Björn Persson
3 siblings, 0 replies; 37+ messages in thread
From: Björn Persson @ 2010-05-22 12:53 UTC (permalink / raw)
Ludovic Brenta wrote:
> Björn Persson writes on comp.lang.ada:
>> Is that libgnat-4.3-dbg that needs to be installed (on Etch)?
>
> Yes. More precisely, libgnat-4.1-dbg on Etch, libgnat-4.3-dbg on Lenny
> and libgnat-4.4-dbg on Squeeze. If the code names are too confusing,
> version numbers are useful, too :)
Yeah, I got the names mixed up. Now we can be embarrassed together.
> 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.
When I first tried to use it and it failed, I thought it had something to do
with that note in g-trasym.ads about shared libraries. I thought maybe
symbolic traceback would only work in statically linked programs or
something. Apparently Dmitry read it in a similar way. Maybe others also
read it that way, and therefore didn't report the problem.
--
Björn Persson
PGP key A88682FD
^ permalink raw reply [flat|nested] 37+ messages in thread