* Help with gnat storage error @ 1997-06-23 0:00 Myriam Witt 1997-06-24 0:00 ` Kirk Beitz ` (3 more replies) 0 siblings, 4 replies; 6+ messages in thread From: Myriam Witt @ 1997-06-23 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Help with gnat storage error 1997-06-23 0:00 Help with gnat storage error Myriam Witt @ 1997-06-24 0:00 ` Kirk Beitz 1997-06-24 0:00 ` Stephen Leake ` (2 subsequent siblings) 3 siblings, 0 replies; 6+ messages in thread From: Kirk Beitz @ 1997-06-24 0:00 UTC (permalink / raw) To: kroemer 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Help with gnat storage error 1997-06-23 0:00 Help with gnat storage error Myriam Witt 1997-06-24 0:00 ` Kirk Beitz @ 1997-06-24 0:00 ` Stephen Leake 1997-06-25 0:00 ` Peter Hermann 1997-06-26 0:00 ` Myriam Witt 1997-06-28 0:00 ` Robert Dewar 3 siblings, 1 reply; 6+ messages in thread From: Stephen Leake @ 1997-06-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Help with gnat storage error 1997-06-24 0:00 ` Stephen Leake @ 1997-06-25 0:00 ` Peter Hermann 0 siblings, 0 replies; 6+ messages in thread From: Peter Hermann @ 1997-06-25 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Help with gnat storage error 1997-06-23 0:00 Help with gnat storage error Myriam Witt 1997-06-24 0:00 ` Kirk Beitz 1997-06-24 0:00 ` Stephen Leake @ 1997-06-26 0:00 ` Myriam Witt 1997-06-28 0:00 ` Robert Dewar 3 siblings, 0 replies; 6+ messages in thread From: Myriam Witt @ 1997-06-26 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Help with gnat storage error 1997-06-23 0:00 Help with gnat storage error Myriam Witt ` (2 preceding siblings ...) 1997-06-26 0:00 ` Myriam Witt @ 1997-06-28 0:00 ` Robert Dewar 3 siblings, 0 replies; 6+ messages in thread From: Robert Dewar @ 1997-06-28 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1997-06-28 0:00 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-06-23 0:00 Help with gnat storage error Myriam Witt 1997-06-24 0:00 ` Kirk Beitz 1997-06-24 0:00 ` Stephen Leake 1997-06-25 0:00 ` Peter Hermann 1997-06-26 0:00 ` Myriam Witt 1997-06-28 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox