From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,fea50f781bb229dc
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news3.google.com!feeder.news-service.com!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!.POSTED!not-for-mail
From: "Alex R. Mosteo" <alejandro@mosteo.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Symbolic tracebacks on Debian
Followup-To: comp.lang.ada
Date: Tue, 25 May 2010 11:02:13 +0200
Organization: A noiseless patient Spider
Message-ID: <htg3o7$rbl$1@news.eternal-september.org>
References: <xpapqc7al1kx$.10dcevapcbh68.dlg@40tude.net>
 <85f51aeb-cac9-4591-921a-a7f50c8ef142@a21g2000yqn.googlegroups.com>
 <1pup1z7a4f1pq$.of30sejrqe4m.dlg@40tude.net>
 <87hbmae33k.fsf@ludovic-brenta.org> <85j595F1lqU1@mid.individual.net>
 <87sk5navk6.fsf_-_@ludovic-brenta.org> <82bpc8s17m.fsf@stephe-leake.org>
 <C81D7888.14413C%yaldnif.w@blueyonder.co.uk> <m2aarsuqis.fsf@pushface.org>
 <82eih2rblr.fsf@stephe-leake.org> <m2632evcn3.fsf@pushface.org>
 <C81F33EC.14438D%yaldnif.w@blueyonder.co.uk> <m21vd2v1sc.fsf@pushface.org>
 <82fx1hr7pl.fsf@stephe-leake.org> <m2wrutt8lx.fsf@pushface.org>
 <82fx1gafu0.fsf@stephe-leake.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
Injection-Date: Tue, 25 May 2010 09:03:04 +0000 (UTC)
Injection-Info: mx01.eternal-september.org;
 posting-host="CgeQJFhmVqlm7PSKqn5RPQ";
	logging-data="28021"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+bgp4ORyik1qx1DwWqPLfB"
User-Agent: KNode/4.4.3
Cancel-Lock: sha1:x1r+Aw0jdydRkzXvkS8PLmN7NwM=
Xref: g2news2.google.com comp.lang.ada:11959
Date: 2010-05-25T11:02:13+02:00
List-Id: <comp.lang.ada>

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.