Prev: Ada Debian policy plea
Next: info version of Ada reference manuals
From: Ludovic Brenta on 25 May 2010 04:39
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.
From: Alex R. Mosteo on 25 May 2010 05:02
Stephen Leake wrote:

> Simon Wright <simon(a)pushface.org> writes:
>
>> 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:
>>>>
>>>>> 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.
From: Simon Wright on 25 May 2010 15:16
Stephen Leake <stephen_leake(a)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.
From: Stephen Leake on 26 May 2010 03:30
Simon Wright <simon(a)pushface.org> writes:

> Stephen Leake <stephen_leake(a)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
First  |  Prev  | 
Pages: 1 2 3 4
Prev: Ada Debian policy plea
Next: info version of Ada reference manuals