Re: Symbolic tracebacks on Debian

["Alex R. Mosteo" <alejandro@mosteo.invalid>]

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.