Prev: SPARK reserved and predefined words : alternative choices
Next: Ada noob here! Is Ada widely used?
From: Ludovic Brenta on 20 May 2010 03:20
Björn Persson writes on comp.lang.ada:
> Ludovic Brenta wrote:
>
>> Traceback is always available, either in symbolic or numeric form. To
>> get the symbolic form, you need the -dbg package installed.
>
> Is that libgnat-4.3-dbg that needs to be installed (on Etch)?

Yes. More precisely, libgnat-4.1-dbg on Etch, libgnat-4.3-dbg on Lenny
and libgnat-4.4-dbg on Squeeze. If the code names are too confusing,
version numbers are useful, too :)

> I can't get symbolic traceback to work; I get Storage_Error
> instead. Below is my test program and how I compile and run it. Do you
> have any idea of what's wrong?

I investigated and discovered this is a genuine bug in the patched
convert_addresses which now expects an additional argument; I never
noticed this upstream change:

2007-04-06 Olivier Hainque <hainque(a)adacore.com>

* adaint.c:
(convert_addresses): Adjust prototype and dummy definition to expect an
extra file_name argument.

* gmem.c (__gnat_convert_addresses): Wrapper to convert_addresses,
filling the now expected file_name argument with the appropriate
argv[0] expansion.
(__gnat_gmem_a2l_initialize, __gnat_gmem_read_next_frame): Use it.
(tracebk): Array of void * instead of char *, corresponding to what
convert_addresses expects.
(exename): New static global, to hold the executable file name to be
used in all convert_addresses invocations.
(gmem_read_backtrace, __gnat_gmem_symbolic): Account for tracebk type
change.
(__gnat_gmem_a2l_initialize): Resolve exename.
(__gnat_convert_addresses): Use exename as the convert_addresses
file_name argument.

* g-trasym.adb (Symbolic_Traceback): Adjust signature of imported
"convert_addresses", now expecting a filename argument. Import the
necessary entities to compute the filename to use and pass it to
convert_addresses.

(Subversion revision 123544 on the trunk). Consequently I never
adjusted convert_addresses.c accordingly.

On the one hand, this is quite embarrassing as it means that both
gnat-4.3 and gnat-4.4 are broken in this respect. On the other hand,
since nobody noticed or reported this problem before you and gnat-4.3
has been in Debian since 2008-01-30, I'm starting to wonder whether
symbolic tracebacks are all that useful.

Nevertheless, this deserves a bug in the Debian bug tracking system and
a fix before the release of Squeeze. Thanks for reporting!

--
Ludovic Brenta.
From: Alex R. Mosteo on 20 May 2010 04:38
Ludovic Brenta wrote:

> Björn Persson writes on comp.lang.ada:
>> Ludovic Brenta wrote:
>(...)
>
> On the one hand, this is quite embarrassing as it means that both
> gnat-4.3 and gnat-4.4 are broken in this respect. On the other hand,
> since nobody noticed or reported this problem before you and gnat-4.3
> has been in Debian since 2008-01-30, I'm starting to wonder whether
> symbolic tracebacks are all that useful.

I'm not user of the debian packages, but I would be quite lost without full
stack backtraces.

Alex.

>
> Nevertheless, this deserves a bug in the Debian bug tracking system and
> a fix before the release of Squeeze. Thanks for reporting!
>

From: Dmitry A. Kazakov on 20 May 2010 10:04
On Thu, 20 May 2010 09:20:25 +0200, Ludovic Brenta wrote:

> On the other hand,
> since nobody noticed or reported this problem before you and gnat-4.3
> has been in Debian since 2008-01-30, I'm starting to wonder whether
> symbolic tracebacks are all that useful.

Symbolic traceback is an integral part of GtkAda contributions. Its trace
window can dump, decode, navigate symbolic traceback. It is essential when
debugging GtkAda programs.

(I didn't use Debian until recent time)

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Ludovic Brenta on 21 May 2010 08:26
Alex R. Mosteo wrote on comp.lang.ada:
> Ludovic Brenta wrote:
> > Björn Persson writes on comp.lang.ada:
> >> Ludovic Brenta wrote:
> >(...)
>
> > On the one hand, this is quite embarrassing as it means that both
> > gnat-4.3 and gnat-4.4 are broken in this respect.  On the other hand,
> > since nobody noticed or reported this problem before you and gnat-4.3
> > has been in Debian since 2008-01-30, I'm starting to wonder whether
> > symbolic tracebacks are all that useful.
>
> I'm not user of the debian packages, but I would be quite lost without full
> stack backtraces.
>
> Alex.
>
>> Nevertheless, this deserves a bug in the Debian bug tracking system and
>> a fix before the release of Squeeze.  Thanks for reporting!

I filed a bug report and am testing a fix; I'll probably upload it on
Tuesday or Wednesday. See http://bugs.debian.org/582452 and followup
there if you want.

--
Ludovic Brenta.
From: Björn Persson on 22 May 2010 08:53
Ludovic Brenta wrote:

> Björn Persson writes on comp.lang.ada:
>> Is that libgnat-4.3-dbg that needs to be installed (on Etch)?
>
> Yes. More precisely, libgnat-4.1-dbg on Etch, libgnat-4.3-dbg on Lenny
> and libgnat-4.4-dbg on Squeeze. If the code names are too confusing,
> version numbers are useful, too :)

Yeah, I got the names mixed up. Now we can be embarrassed together.

> On the other hand,
> since nobody noticed or reported this problem before you and gnat-4.3
> has been in Debian since 2008-01-30, I'm starting to wonder whether
> symbolic tracebacks are all that useful.

When I first tried to use it and it failed, I thought it had something to do
with that note in g-trasym.ads about shared libraries. I thought maybe
symbolic traceback would only work in statically linked programs or
something. Apparently Dmitry read it in a similar way. Maybe others also
read it that way, and therefore didn't report the problem.

--
Björn Persson
PGP key A88682FD
 | 
Pages: 1
Prev: SPARK reserved and predefined words : alternative choices
Next: Ada noob here! Is Ada widely used?