GNAT compiler problem?

GNAT compiler problem?

[Rusnak]

I have been coding in Ada on a large project recently and until recently
have had little problems.  Unfortunately,
my program recenlty coughed up a Storage_Error which surprised me.
After removing my new code and putting it back
in piece by piece, I got a genuine segmentation fault.  I used gdb to
help analyze the code, and found that it was crashing on
a type definition.   (The actual compiler-mangled procedure name was
somethling like "my_package___read").  The type definition was a type
derived off
of a (base) tagged type.

I then set a breakpoint there and  reran the code.  After stepping
through the code after the first break, I found that the code execution
was going through an infinite loop
on  type definitions:  that is to say,    the call to
"my_package___read" (which the debugger indicated as originating from
the type
definition) called a procedure named something like
"base_package___read_2" (originating at the base class type
definition).  It then
called "my_package_read" again and so the cycle goes.    I assume that
the "read" is an internal procedure defined internally to the compiler,
since no such procedure exists in either of the packages (name mangling
in Ada by this compiler seems rather straightforward).

Has anyone seen this behavior before?

Thanks

-John

Re: GNAT compiler problem?

[Tucker Taft]

Rusnak (jrusnakzzz@netgate.net) wrote:
: I have been coding in Ada on a large project recently and until recently
: have had little problems.  Unfortunately,
: my program recenlty coughed up a Storage_Error which surprised me.
: After removing my new code and putting it back
: in piece by piece, I got a genuine segmentation fault.  I used gdb to
: help analyze the code, and found that it was crashing on
: a type definition.   (The actual compiler-mangled procedure name was
: somethling like "my_package___read").  The type definition was a type
: derived off
: of a (base) tagged type.

: I then set a breakpoint there and  reran the code.  After stepping
: through the code after the first break, I found that the code execution
: was going through an infinite loop
: on  type definitions:  that is to say,    the call to
: "my_package___read" (which the debugger indicated as originating from
: the type
: definition) called a procedure named something like
: "base_package___read_2" (originating at the base class type
: definition).  It then
: called "my_package_read" again and so the cycle goes.    I assume that
: the "read" is an internal procedure defined internally to the compiler,
: since no such procedure exists in either of the packages (name mangling
: in Ada by this compiler seems rather straightforward).

The "__read" operation is probably the compiler-generated 'Read routine
(a "stream" attribute), which is used automatically as part of the 
distribution annex for message "unmarshalling", as well as by explicit 
uses of the 'Read attribute and 'Input attribute.  Are you making use of 
any of these features?

: Has anyone seen this behavior before?

: Thanks

: -John

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: GNAT compiler problem?

[Rusnak]

>

  Thanks for the reply.  Unfortunatey, I am not using any of these features
explicitly.  The problem is looking like a memoery problem.
I fixed the problem above by doing the folllowing:
    I was implementing some new code in stages, and the first stage involved
a package which only contained a child package and nothing else.
The child package contained a type definiction (derived/subclassed off of a
tagged type in another package).  This code caused an error, but when I
instead "promoted" the child package to acutally be its parent package (that
is, I pushed the internals of the child package to the parent package and
eliminated the child), the code worked fine.  I lived with this solution for
a while but a new error recently creeped at a point where a cast was being
mase from an anonymous access type to a "defined type" (pardon my ignorance
of the proper terminology).  A STORAGE_ERROR was raised in a routine in
Ada.Tags
for checking that validity of the conversion I assume .  I shifted the
explicit cast call to a different location in the code and things worked fine
once again.
Later, I found that a section of code that was working before no longer is,
with a CONSTRAINT_ERROR when using the Value attribute to convert a
String to an enumerated type.  When I put a debugging statement in to print
the 'Image of  a value within the enumerated type, the program caused a
segmentation fault/core dump.  It seems that some section of memory is
getting "stomped" on and overwritten.

I do allocate memorty, but no deallocation of memory is done at that point of
execution.

It looks like this will be a long battle to determine the cause.


-John