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!feeder3.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.78.MISMATCH!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Symbolic tracebacks on Debian Date: Tue, 25 May 2010 20:16:48 +0100 Organization: A noiseless patient Spider Message-ID: References: <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> <82eih2rblr.fsf@stephe-leake.org> <82fx1hr7pl.fsf@stephe-leake.org> <82fx1gafu0.fsf@stephe-leake.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Tue, 25 May 2010 19:16:48 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="KCXegvZb5vh43D+f3BR6Ew"; logging-data="15810"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18WrZBY3HuXu3MO3Zmh2+6RjOUm2LUMHl4=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (darwin) Cancel-Lock: sha1:zIqBTTTScnGjqTjqPvvIiOmwzTM= sha1:MceAFaRIW4hBA6QCqHG6c+S5QFI= Xref: g2news2.google.com comp.lang.ada:11983 Date: 2010-05-25T20:16:48+01:00 List-Id: Stephen Leake 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.