Postmortem debugging with ada ?

Postmortem debugging with ada ?

[Alfred Hilscher]

Hi,

in my early DOS days I worked with the Logitech Modula-2 compiler. This
tool had a nice feature called postmortem debugging. If a programm
crashes (e.g. due to rangeoverflow, indexunderflow etc.) it produced a
dump file which could be analyzed symbolically. So if a program (with
enabled checkes) failed by some user, he could send this dump file to
the developer and this one then could simple find the location and the
reason by inspecting the call chain and the data. 

Is there a similar way with GNAT or Aonix (e.g. in case of
constraint_error) ?

Re: Postmortem debugging with ada ?

[Jacob Sparre Andersen]

Alfred:

> Is there a similar way with GNAT or Aonix (e.g. in case of
> constraint_error) ?

On Unix-like systems you are generally able to get a "core dump"
from a crashed program. GVD should be able to load this so you
can inspect it.

I know that debuggers can introduce/remove errors not found in
the wild, but have you considered running the program inside a
debugger, before you try using core dumps?

Jacob (who hasn't looked at core dumps for years)
-- 
Harddiske er bin�re enheder: Enten er de nye, eller ogs� er de fyldt op.

Re: Postmortem debugging with ada ?

[Des Walker]

Jacob Sparre Andersen wrote:
> 
> Alfred:
> 
> > Is there a similar way with GNAT or Aonix (e.g. in case of
> > constraint_error) ?
> 
> On Unix-like systems you are generally able to get a "core dump"
> from a crashed program. GVD should be able to load this so you
> can inspect it.
> 
> I know that debuggers can introduce/remove errors not found in
> the wild, but have you considered running the program inside a
> debugger, before you try using core dumps?
> 
> Jacob (who hasn't looked at core dumps for years)
> --
> Harddiske er bin�re enheder: Enten er de nye, eller ogs� er de fyldt op.

Hi,

we've used gdb to analyse core files from Ada (compiled with GNAT and -g
switch) for a few years now. This worked fine, even with high levels of
code optimisation, with the startup location being the point at which
the unhandled exception was raised. It was easy to check the thread
stack to get the context.

Applications were running on SPARC under Solaris 2.5.x and 2.6, and also
on Pentium under Linux.

When running the application under the debugger control (gdb), we found
it best to trap exceptions by breaking on __gnat_raise. But as I can't
recall why, that may not be relevant :)

	HTH
	Des Walker
	Alenia-Marconi Systems

Re: Postmortem debugging with ada ?

[Marc A. Criley]

Des Walker wrote:
> 
> When running the application under the debugger control (gdb), we found
> it best to trap exceptions by breaking on __gnat_raise. But as I can't
> recall why, that may not be relevant :)

The Ada-aware variant of gdb provides the "break exception" command,
which in effect does this.

(If you're using the ALT distribution of GNAT for Linux, the Ada aware
version of gdb is called gnatgdb.)

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com

Re: Postmortem debugging with ada ?

[Alfred Hilscher]

Des Walker wrote:
> 
> Jacob Sparre Andersen wrote:
> >
> > Alfred:
> >
> > > Is there a similar way with GNAT or Aonix (e.g. in case of
> > > constraint_error) ?
> >
> > On Unix-like systems you are generally able to get a "core dump"
> > from a crashed program. GVD should be able to load this so you
> > can inspect it.

What means "a crashed program" ? Does this also include Ada exceptions
or only "hard" crashes (illegal pointer reference)that are recognized by
the OS (instead by Ada RTS) ?

BTW: I forgot - I work on WinNT.

> >
> > I know that debuggers can introduce/remove errors not found in
> > the wild, but have you considered running the program inside a
> > debugger, before you try using core dumps?


What I want do is, give the (tested) application to the end user, and
react only if he reports an error. I think the user don't accept to run
the app within a debugger.


 
> Hi,
> 
> we've used gdb to analyse core files from Ada (compiled with GNAT and -g
> switch) for a few years now. This worked fine, even with high levels of
> code optimisation, with the startup location being the point at which
> the unhandled exception was raised. It was easy to check the thread
> stack to get the context.


Do you get symbolic values for (procedure) local and global variables ?

 
> Applications were running on SPARC under Solaris 2.5.x and 2.6, and also
> on Pentium under Linux.

Do you know whether there is a way under Winxx ?

Re: Postmortem debugging with ada ?

[Stephen Leake]

Alfred Hilscher <Alfred.Hilscher@icn.siemens.de> writes:

> Hi,
> 
> in my early DOS days I worked with the Logitech Modula-2 compiler. This
> tool had a nice feature called postmortem debugging. If a programm
> crashes (e.g. due to rangeoverflow, indexunderflow etc.) it produced a
> dump file which could be analyzed symbolically. So if a program (with
> enabled checkes) failed by some user, he could send this dump file to
> the developer and this one then could simple find the location and the
> reason by inspecting the call chain and the data. 
> 
> Is there a similar way with GNAT or Aonix (e.g. in case of
> constraint_error) ?

Others have mentioned using gdb with core dumps. 

Another approach is to output a symbolic stack trace. GNAT provides
the package GNAT.Traceback.Symbolic. This allows your users to not
have gdb installed; a good feature.

-- 
-- Stephe