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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,50ad4ada98045ba X-Google-Attributes: gid103376,public From: mgk25@cl.cam.ac.uk (Markus Kuhn) Subject: Re: locating exceptions (was: Ada success story) Date: 1999/03/18 Message-ID: <7cqga8$llt$1@pegasus.csx.cam.ac.uk>#1/1 X-Deja-AN: 456052558 References: <119fb4e248%hubersn@lcs.wn.bawue.de> <36efef1c.3265725@news.pacbell.net> <7cp9cp$743$1@nnrp1.dejanews.com> Organization: U of Cambridge Computer Lab, UK Newsgroups: comp.lang.ada Date: 1999-03-18T00:00:00+00:00 List-Id: dennison@telepath.com writes: |> In article <36efef1c.3265725@news.pacbell.net>, |> tmoran@bix.com (Tom Moran) wrote: |> > I well remember one early demo where the program got a |> > Constraint_Error at such and such a line number. Within a few minutes |> > I had it explained, fixed, recompiled, and was re-running the demo. |> > The client was impressed. In C there would have been no error, just |> > bad data in the database. |> |> I sure wish more compiler vendors made this information (line number of an |> exception occurrence) available without using a debugger. Or better produce a core dump (which contains much more info than just the line number). That is actually the single thing I particularly dislike about the current GNAT version: An unhandeled exception gives you no useful information whatsoever unless you had the application running in a debugger. But you use a debugger normally only if you expect an error, so unexpected constraint errors cause a lot of hazzle to locate (rerun everything inside gdb in the hope you can reproduce the circumstances). Things where actually easier in C: If you got a segmentation violation, the OS would produce a core dump, in which you then can locate with gdb not only the place where the process violated its memory limits, but you also could inspect the values of variables that led to this. GNAT's Ada code practically never produced a core dump, which can be very inconvenient. It would be a very significant improvement if the code produced by GNAT with option -g would always produce a core dump as a result of an unhandeled exception, with the program counter at the place where the exception was first triggered and the call stack of all threads intact. Then I could claim that debugging Ada is really more convenient than debugging C because then I could use gdb as easily to dig around in the extremely useful core files. Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: