Re: Symbolic tracebacks on Debian

[Stephen Leake <stephen_leake@stephe-leake.org>]

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