GNAT exception traceback 
Author Message
 GNAT exception traceback

I have a question regarding exception tracing under the GNAT Ada95
compiler.

Running GNAT 3.05 on DOS 6.x and GNAT 3.07 on Solaris 2.5.1. On both
platforms, when an exception is raised and propagated to the top level
procedure ("main") and not caught, the code generated by the GNAT
compiler, correctly, reports "raised ADA.IO_EXCEPTIONS.DEVICE_ERROR" for
instance.
My question is, without running gdb or adding additional exception
handlers, is it possible to generate traceback information to determine
which line of code in which package generated the exception, and if so
how ?

For example:
    CONSTRAINT_ERROR exception raised in package XXX line i
    CONSTRAINT_ERROR exception propagated out of package YYY line j
    CONSTRAINT_ERROR exception propagated out of package Main line k

Thanks for any help.  

--
Steve Gibson
ADI Limited, CCIS Systems Group

Snail: 22 Stirling Hwy
       Nedlands
       Western Australia
Nbrs : (tel) +61 9 333 8917    (fax) +61 9 333 8889



Sun, 28 Nov 1999 03:00:00 GMT  
 GNAT exception traceback

Steve asks

<<My question is, without running gdb or adding additional exception
handlers, is it possible to generate traceback information to determine
which line of code in which package generated the exception, and if so
how ?
 >>

You need to run gdb to get the traceback. This is easy to do, so it is
not clear why you set the precondition of not using it (your question is
a bit like saying: can I use GNAT to compile my Ada program without
using gcc -- the answer in both cases is no!)



Mon, 29 Nov 1999 03:00:00 GMT  
 GNAT exception traceback

Quote:
> You need to run gdb to get the traceback. This is easy to do, so it is
> not clear why you set the precondition of not using it (your question
> is
> a bit like saying: can I use GNAT to compile my Ada program without
> using gcc -- the answer in both cases is no!)

I think this feature (traceback without gdb) would be very useful. It would
allow us to have a trace of errors occurring at our customers' sites without
reproducing the bug in our environment, which is often impossible.


Tue, 30 Nov 1999 03:00:00 GMT  
 GNAT exception traceback

Quote:
>> You need to run gdb to get the traceback. This is easy to do, so it is
>> not clear why you set the precondition of not using it (your question
>> is
>> a bit like saying: can I use GNAT to compile my Ada program without
>> using gcc -- the answer in both cases is no!)

>I think this feature (traceback without gdb) would be very useful. It would
>allow us to have a trace of errors occurring at our customers' sites without
>reproducing the bug in our environment, which is often impossible.

I'd think dumping a core would be nice; at least you can look at the call
stack. But doing it the C way would be sacrilegious, right?




Tue, 30 Nov 1999 03:00:00 GMT  
 GNAT exception traceback

Huy says

<<
I'd think dumping a core would be nice; at least you can look at the call
stack. But doing it the C way would be sacrilegious, right?
 >>

No, that's the point, you can't look at the call stack in a core dump, because
by the time you know an exception is unhandled, it's too late, the stack has
been unwound and destroyed. This is something that needs improving in future
versions of GNAT (the SGI version of GNAT using WORKSHOP handles this nicely
right now).



Tue, 30 Nov 1999 03:00:00 GMT  
 GNAT exception traceback

Quote:

> Steve asks

> <<My question is, without running gdb or adding additional exception
> handlers, is it possible to generate traceback information to determine
> which line of code in which package generated the exception, and if so
> how ?

> You need to run gdb to get the traceback. This is easy to do, so it is
> not clear why you set the precondition of not using it (your question is
> a bit like saying: can I use GNAT to compile my Ada program without
> using gcc -- the answer in both cases is no!)

I believe that Steve's question does have merit.

I was going to wait until I had studied the implementation of exception
handling in GNAT before posting a similar question but since someone
brought it up here goes ...

We develop applications written in Ada for use in embedded systems.  Due
to limited resources in the embedded target, the production code is
generally delivered with a few judiciously placed exception handlers in
outer scopes to recover the system just in case something slipped
through testing and propogates an unhandled exception.

The systems are first subjected to extreme operating conditions while
many miles away from the software developers and a de{*filter*}.  If an
error occurs it is often not repeatable due to the complex environment
that the system is in.

This means that we get just one chance to collect all possible
information about what the software was doing at the point that an
exception was propagated.

It would be an EXTREMELY valuable capability if the
Ada.Exceptions.Exception_Information function carried with it some
information about where the exception was originally raised or even
better a full traceback.

This may be too much baggage to justify implementation in the compiler
but nevertheless it would provide a useful capability to a certain group
of users.

-------------
Aaron Metzger



Wed, 01 Dec 1999 03:00:00 GMT  
 GNAT exception traceback

(snip)

Quote:
> My question is, without running gdb or adding additional exception
> handlers, is it possible to generate traceback information to determine
> which line of code in which package generated the exception, and if so
> how ?

> For example:
>     CONSTRAINT_ERROR exception raised in package XXX line i
>     CONSTRAINT_ERROR exception propagated out of package YYY line j
>     CONSTRAINT_ERROR exception propagated out of package Main line k

(snip)

Why not simply add an exception handler to each subprogram, which will
store the name of the subprogram (or simply echo the name to the
terminal) and then re-raise the exception.

...
exception
   when others => Trace_Exception(Package_Name,
                                  Subprogram_Name);
                  raise;
end Subprogram;

The final handler (i.e. the main program) can print/store the name of
the raised exception (using Ada.Exceptions.Name), together with a
message to the user.

If it seems like to much work, use a script to insert the extra lines,
or only add the handler to routines that are "at the start of" the call
chain.

We use this approach at work, since our customers use classified
(military) input files, so we generally can't recreate the error.
The exception trace file provides at least a clue to what went wrong.

/Martin.



Wed, 01 Dec 1999 03:00:00 GMT  
 GNAT exception traceback

Aaron says

<<It would be an EXTREMELY valuable capability if the
Ada.Exceptions.Exception_Information function carried with it some
information about where the exception was originally raised or even
better a full traceback.

This may be too much baggage to justify implementation in the compiler
but nevertheless it would provide a useful capability to a certain group
of users.>>

No quarrel with that. At least providing the location where the exception
was raised is perfectly feasible if you are willing to accept some additional
space overhead in your program to store the neccessary information, and this
is something that will get added to GNAT one of these days (so far it is not
a feature that any of our customers have had at the top of their priority
lists, so hence it is not at the top of ours).

Full tracebacks are another matter. There are serious performance penalities
in making exception occurrences be of arbitrary length, and also some very
{*filter*} cases. In particular, if you force allocation of exceptoin occurrences
on the heap, which obviously is whaat has to be done if the information is
variable length, then you really have problems with Storage_Error. There is
also a question of exactly where this information gets released. The reason
that exception messages can be limited in length by an implementation is
precisely to avoid this kind of problem (see the AARM for further details).



Wed, 01 Dec 1999 03:00:00 GMT  
 GNAT exception traceback

Quote:

>Full tracebacks are another matter. There are serious performance penalities
>in making exception occurrences be of arbitrary length, and also some very
>{*filter*} cases. ...

How about storing a fixed-length traceback?  Usually the top few stack
frames are enough for debugging.  So you could pick some number, say 40
stack frames, and store that many from the top of the stack.  No need to
use the heap, unless the programmer explicitly copies it to the heap.
Or maybe the top 30 and bottom 10.  Or maybe make it user configurable.

Although Exception_Information returns a String, the traceback data
should be stored internally in a more compact form (a series of return
addresses, or some such), and converted to String when E_I is called.

- Bob



Wed, 01 Dec 1999 03:00:00 GMT  
 GNAT exception traceback

Mats says

<<I think this feature (traceback without gdb) would be very useful. It would
allow us to have a trace of errors occurring at our customers' sites without
reproducing the bug in our environment, which is often impossible.>>

When our customers start saying the same thing and putting this at the top
of the list, and are willing to pay the high development cost associated
with this feature (it is a large amount of work, because it is highly
target dependent, and we avoid target dependent stuff where we can to maintain
the easy portability of GNAT), then maybe it will get done.

But I doubt it, the cost/benefit ratio is probably too high for this feature
to see the light of day.

What is however, much more practical, and which is definitely on the list of
things to do is to have the runtime clearly detect an unhandled exception
with the run time stack intact. That will be implemented as part of our
current work in reimplementing the exception mechanism generally.

Then you can simply dump core at the point where such an error occurs, and
analyze the core dump with gdb later. This gives essentially equivalent
capability with two big advantages:

1) no overhead in the running program to allow for the generation of tracebacks

2) no target dependent work required in the runtime, other than the basic
work to handle exception handling, which is needed in any case.

Robert Dewar
Ada Core Technologies

P.S. the VMS implementation of GNAT *does* provide full tracebacks. That's
because it is part of the VMS ABI. Too bad that all manufacturers do not
pay attention to the exception issue when they specify ABI's. Not only
has Digital always carefully considered these issues, but they have always
had significant Ada input in the design process, so their design for system
ABI level handling of exceptions is nicely consistent with the requirements
in Ada.



Wed, 01 Dec 1999 03:00:00 GMT  
 GNAT exception traceback

Steve says

<<Why not simply add an exception handler to each subprogram, which will
store the name of the subprogram (or simply echo the name to the
terminal) and then re-raise the exception.>>

Two things to be aware of with this suggestion.

1. If your compiler uses an approach that costs entry time when an exception
handler is declared, this might cause significant slow down in execution
time. GNAT is currently like this. This approach results in fast exception
propagation but at the cost of slow setup time on handlers. That of course
is the wrong tradeoff (it is a lot of difficult target dependent work to
do the proper zero cost solution, and we are working on that now).

2. If your compiler *does* generate nice trace backs on unhandled exceptions,
then you will undermine it by this approach.

In particular, when we get the feature put in of avoiding destroying the
stack on an unhandled exception, then you will be able to breakpoint on
an unhandled exception and get a nice detailed traceback from GDB (with
all the arguments at each level etc). You will undermine this capability
if you put exception handlers in every procedure.

Note: if your program does not in general use Constraint_Error as a control
flow mechanism, i.e. you do not have any exception handlers for
Constraint_Error in your program, or when others handlers, then you can
do something quite easily now which may be useful in some cases. Simply
add code at __gnat_raise to check if the exception is constraint error,
and if so, abort. \

Then you will get a core dump which you can examine at leisure using GDB.



Wed, 01 Dec 1999 03:00:00 GMT  
 GNAT exception traceback

I have been seeing a lot of e-mails regarding tracebacks.  Correct me
if I am wrong but doesn't the DOS version of GNAT provide tracebacks?
If so then, how hard would it be to incorporate this software into other
releases?

Later...

Chris Sparks



Fri, 03 Dec 1999 03:00:00 GMT  
 GNAT exception traceback

Quote:

>> You need to run gdb to get the traceback. This is easy to do, so it is
>> not clear why you set the precondition of not using it (your question
>> is
>> a bit like saying: can I use GNAT to compile my Ada program without
>> using gcc -- the answer in both cases is no!)
> I think this feature (traceback without gdb) would be very useful. It would
> allow us to have a trace of errors occurring at our customers' sites without
> reproducing the bug in our environment, which is often impossible.

The ``ez2load'' GNAT (PC) has a traceback utility without manual use of gdb
- showing parameter values, source code lines (even with generics).

G.



Fri, 03 Dec 1999 03:00:00 GMT  
 
 [ 46 post ]  Go to page: [1] [2] [3] [4]

 Relevant Pages 

1. GNAT : Exception traceback

2. Verdix Exception Traceback history

3. traceback exceptions

4. Exception handling and traceback from Python/C API

5. Syntax error exceptions, PyErr_Print, and tracebacks

6. Marshal dumping of exception tracebacks

7. Printing the exception traceback in C code

8. Traceback on Gnat/Linux

9. Bug in GNAT.Traceback.Symbolic?

10. How to get a traceback in Gnat 3.14p

11. Problem using Gnat.Traceback.Symbolic.Symbolic_Traceback()

12. GNAT.Traceback is back...

 

 
Powered by phpBB® Forum Software