Re: Stack size with GNAT for Windows

Re: Stack size with GNAT for Windows

[gautier]

About this affair: there was indeed a bug in
the source location given by Storage_error and
another one that generated that Storage_error:
a loop with somewhere a "An_Array:= (others=> False)".
So it could be a memory leak, since there is
no allocation in that loop.
With "for i in An_Array'range loop An_Array(i):= False;
end loop" everything goes well.
Little moral: debug with "Put()", and in 2001
the ":= (others=> False)"-likes are not yet robust
(at least on the compilers I've met).

Thanks for help.

__________________________________________
Gautier  --  http://www.diax.ch/users/gdm/

Stack size with GNAT for Windows

[gautier]

Hello. Sorry for the banal question, but is there
a mean to increase the stack size with GNAT (3.13p)
for Windows ? I obtain a stack overflow in a numerics
program for a middle-sized problem, with all big data
taken on heap (via New), this when entering a procedure
with only 3 integer as local variables. So, I suspect
a bug, but would like to test a bit before sending a bug
report. Of course I have searched through the GNAT user's
guide and what remains of Deja News.

TIA

__________________________________________
Gautier  --  http://www.diax.ch/users/gdm/

Re: Stack size with GNAT for Windows

[Marc A. Criley]

gautier@club.lemonde.fr wrote:
> 
> Hello. Sorry for the banal question, but is there
> a mean to increase the stack size with GNAT (3.13p)
> for Windows ? I obtain a stack overflow in a numerics
> program for a middle-sized problem, with all big data
> taken on heap (via New), this when entering a procedure
> with only 3 integer as local variables. So, I suspect
> a bug, but would like to test a bit before sending a bug
> report. Of course I have searched through the GNAT user's
> guide and what remains of Deja News.

With only 3 integer local variables, it would seem stack size is only
part of the story.  I ran into a similar problem, though, with the 3.13
series (a, b1, b2) of GNAT on HP-UX.  The characteristics of the
procedures in which the problem occurred usually involved either large
aggregate assignements (meaning the data item itself was quite large) or
calling a function whose return type was a large data structure.

Presumably the stack is employed as an intermediary when doing these
assignments, and so caused the overflow.

This problem was reported to ACT, as we were a supported customer, and I
_believe_ fixes went into the 3.14 series, of which there is not yet a
public version.

In the meantime, if your procedure does show characteristics like I
described, the way we worked around the problems was by breaking large
aggregate assignments into a series of component assignments, and by
converting the functions into procedures that returned data via an "out"
or "in out" parameter.

On the other hand, if your procedure doesn't have those characteristics,
analyze it to see what other kind of construct may be in it that might
reasonably be expected to require a large amount of intermediate
storage.

Good luck,

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