Help with gnat storage error

Help with gnat storage error

[Myriam Witt]

Hello....

I'm using gnat's binary distribution
gnat-3.09-sparc-sun-solaris2.4-bin.tar.gz
on a SUN Ultra 2, Solaris 2.5.1 (anyone knows about a 2.5.1 binary?).


During compile-/linktime I get some messages 
'warning: creation of object of this type may raise Storage_Error'
from code like 
---
   type T_Polygon_XYZ (Max_Punkte: Natural := 1) is
      record
        Punkte : Natural   := Max_Punkte;  -- Anzahl der Polygonpunkte
        X : T_Vector_Float(1..Max_Punkte) := (others => 0.0);
        Y : T_Vector_Float(1..Max_Punkte) := (others => 0.0);
        Z : T_Vector_Float(1..Max_Punkte) := (others => 0.0);
      end record;

where

   type  T_Vector_Float   is array(integer range <>) of Float;


At runtime my (pure ADA) executables do what they are supposed to but
at exit-time I get: 

raised STORAGE_ERROR

and have to quit the program with ^C. gdb says:

Program received signal SIGBUS, Bus error.
0x10debc in _fini ()
(gdb) bt
#0  0x10debc in _fini ()
#1  0xef69784c in _exithandle ()
#2  0xef6f4174 in exit ()


Funny is the following: some (not all) of my executables terminate
correctly
when called from the directory they are located in but raise the above
storage
error when called from elsewhere (e.g. ../exename).

Any hints?

Thanks in advance

(writing from my girlfriend's account)
--
Eike Kr"omer                                 IABG - Ottobrunn
kroemer@iabg.de
08106/20626                                  089/6088-3313 
              "...but plagiarize, plagiarize, plagiarize, 
            only be sure to always call it please -- research"  
                       (Tom Lehrer: Lobachevsky)

Re: Help with gnat storage error

[Kirk Beitz]

Myriam Witt wrote:
> 
> Hello....
> 
> I'm using gnat's binary distribution
> gnat-3.09-sparc-sun-solaris2.4-bin.tar.gz
> on a SUN Ultra 2, Solaris 2.5.1 (anyone knows about a 2.5.1 binary?).
> 
> During compile-/linktime I get some messages
> 'warning: creation of object of this type may raise Storage_Error'
> from code like
> ---
>    type T_Polygon_XYZ (Max_Punkte: Natural := 1) is
>       record
>         Punkte : Natural   := Max_Punkte;  -- Anzahl der Polygonpunkte
>         X : T_Vector_Float(1..Max_Punkte) := (others => 0.0);
>         Y : T_Vector_Float(1..Max_Punkte) := (others => 0.0);
>         Z : T_Vector_Float(1..Max_Punkte) := (others => 0.0);
>       end record;
> 
> where
> 
>    type  T_Vector_Float   is array(integer range <>) of Float;

you are dealing with the classic "large length discriminant" problem.

you have indicated to the compiler that your record may have a
discriminant whose use is to determine the size of one of the record's
component arrays, and whose range bounds may be as large as Integer'LAST
(which on solaris for gnat3.09 is 2**31-1); therefore, it is technically
possible at run time for each of the component arrays to become that
large.  the compiler cannot know at the time you create the type that
you are never going to create an object:

	BigPolygon : T_Polygon_XYZ((2**31-1));

by doing this, in your case, you would be saying that you need storage
for three arrays each of 2 billion plus points.  this is almost
certainly more memory than your machine can handle.

this can also be a problem even if you don't declare a static variable
of type T_Polygon_XYZ.  if you had an access to T_Polygon_XYZ, and you
declared a new T_Polygon_XYZ of some size based on a run-time generated
value, you could end up causing the need for a huge amount of memory
without truly being able to detect the problem at compile time.

similarly, if T_Polygon_XYZ is used as the type of a parameter in some
subprogram, that subprogram has to be able to properly deal with the
parameter in the cases where the discriminant (and thus the array
lengths of the components) are as low as the default [i.e. 1] or as high
as the largest value of the type used for the discriminant range.

so, gnat (and just about any other ada compiler) gets smart, and when it
sees the original T_Polygon_XYZ, it recognizes that you've put a "really
big" type range in (i don't know what qualifies for "really big" in
gnat), and warns you of the potential problem.

a way to avoid this problem is to figure out a true (or at least
hardly-ever-to-be-met) maximum for the number of points in your polygon
... or whatever similar maximum there might be for other discriminant
types you declare, create a new type that uses those range bounds, and
use that type as your discriminant.

(alternatively, you could simply use variables that are 2D
unconstrained  arrays, or an array whose array components are
unconstrained arrays.  not every case of arrays using length
discriminants can be solved this way, obviously; it's just always best
to use the proper tool to do the job where possible, and
length-discriminanted records whose sole components are arrays is
perhaps a bit of overkill.)

> At runtime my (pure ADA) executables do what they are supposed to but
> at exit-time I get:
> 
> raised STORAGE_ERROR
> 
> and have to quit the program with ^C. gdb says:
> 
> Program received signal SIGBUS, Bus error.
> 0x10debc in _fini ()
> (gdb) bt
> #0  0x10debc in _fini ()
> #1  0xef69784c in _exithandle ()
> #2  0xef6f4174 in exit ()
> 
> Funny is the following: some (not all) of my executables terminate
> correctly
> when called from the directory they are located in but raise the above
> storage
> error when called from elsewhere (e.g. ../exename).

only guessing here, but because generally part of what happens when
leaving scope is re-claiming memory allocated to variables declared
within that stack frame, you may be running into a case where a huge
chunk of memory is getting set aside for the variable object of that
polygon type.  your run-time environment (i.e. environment variables,
arguments, etc.) may be just different enough that the cleanup works
okay in the one instance but not the other.  as i said, though, that is
just a w.a.g. (well...not *just*; knowing this group, it also becomes by
default an effort to bait someone who might really know an answer into
telling me i'm wrong and thereby giving you a more definitive answer...)

--Kirk Beitz
--johndoe@world.std.com

Re: Help with gnat storage error

[Stephen Leake]

Myriam Witt wrote:
> I'm using gnat's binary distribution
> gnat-3.09-sparc-sun-solaris2.4-bin.tar.gz
> on a SUN Ultra 2, Solaris 2.5.1 (anyone knows about a 2.5.1 binary?).
> 
> During compile-/linktime I get some messages
> 'warning: creation of object of this type may raise Storage_Error'
> from code like
> ---
>    type T_Polygon_XYZ (Max_Punkte: Natural := 1) is
>       record
>         Punkte : Natural   := Max_Punkte;  -- Anzahl der Polygonpunkte
>         X : T_Vector_Float(1..Max_Punkte) := (others => 0.0);
>         Y : T_Vector_Float(1..Max_Punkte) := (others => 0.0);
>         Z : T_Vector_Float(1..Max_Punkte) := (others => 0.0);
>       end record;
> 
> where
> 
>    type  T_Vector_Float   is array(integer range <>) of Float;

This is because you might declare:

A : T_Polygon_XYZ (Natural'last);

which would use all of memory (or at least a lot of it!). You should use
a smaller range for Max_Punkte:

type Max_Punkte_Type is range 1 .. 1000;
type T_Polygon_XYZ (Max_Punkte: Max_Punkte_Type := 1) is

You have to pick a reasonable max value, but that is usually not hard.
If you really can not pick a max value, you should be using dynamic
allocation, and a linked list or other structure instead of an array.

-- 
- Stephe

Re: Help with gnat storage error

[Peter Hermann]

Stephen Leake (Stephen.Leake@gsfc.nasa.gov) wrote:
> Myriam Witt wrote:
> >    type T_Polygon_XYZ (Max_Punkte: Natural := 1) is

> type Max_Punkte_Type is range 1 .. 1000;

in order to make live easier for Myriam, Stephen could have said

subtype Max_Punkte_Type is Natural range 1 .. 1000 ;

;-)

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Help with gnat storage error

[Myriam Witt]

Hello....

to keep you up-to-date:

I followed your suggestions and replaced the crucial lines by something
like
   subtype Natural_Constr is Integer range 1..1000;
   type T_Polygon_XYZ (Max_Punkte: Natural_Constr := 1) is
and now don't get any more warnings from the compiler.
The storage error, however, does still occur like before :-(

Are there general hints how to track down something like this (there
are several 100K lines of code envolved (running without (visible) flaw
when using Rational VADS on Solaris or DEC Ada on DecUnix 3.x))?

PS: is there a Solaris 2.5 Version out, yet?

Thanks again...

--
Eike Kr"omer                                 IABG - Ottobrunn
kroemer@iabg.de
08106/20626                                  089/6088-3313 
              "...but plagiarize, plagiarize, plagiarize, 
            only be sure to always call it please -- research"  
                       (Tom Lehrer: Lobachevsky)

Re: Help with gnat storage error

[Robert Dewar]

Myriam says

<<During compile-/linktime I get some messages
'warning: creation of object of this type may raise Storage_Error'
>>

These warnings are correct, you should not ignore warnings like this!
They are warning you that the type you are declaring requires too much
space (in your case, several gigiabytes per object if the default
discriminant value is used).