* GNAT: Why does a large 'new' allocation blow the stack when an initialiser is present ?
@ 2013-11-01 2:49 Rod Kay
2013-11-01 8:45 ` Simon Wright
2013-11-01 10:19 ` sbelmont700
0 siblings, 2 replies; 6+ messages in thread
From: Rod Kay @ 2013-11-01 2:49 UTC (permalink / raw)
Hi all,
Is this a bug ?
procedure bug_Test
is
type Integer_array is array (Integer range <>) of Integer;
the_Array_1 : access Integer_array
:= new Integer_array (1 .. 10_000_000); -- Fine.
the_Array_2 : access Integer_array
:= new Integer_array' (1 .. 10_000_000 => <>); -- Stack overflow.
begin
null;
end;
It seems that, with the initialiser, GNAT is creating the array on the stack before copying it to the final heap memory ?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GNAT: Why does a large 'new' allocation blow the stack when an initialiser is present ?
2013-11-01 2:49 GNAT: Why does a large 'new' allocation blow the stack when an initialiser is present ? Rod Kay
@ 2013-11-01 8:45 ` Simon Wright
2013-11-01 11:23 ` Rod Kay
2013-11-01 15:04 ` Georg Bauhaus
2013-11-01 10:19 ` sbelmont700
1 sibling, 2 replies; 6+ messages in thread
From: Simon Wright @ 2013-11-01 8:45 UTC (permalink / raw)
Rod Kay <rodakay@internode.on.net> writes:
> Hi all,
>
> Is this a bug ?
>
> procedure bug_Test
> is
> type Integer_array is array (Integer range <>) of Integer;
>
> the_Array_1 : access Integer_array
> := new Integer_array (1 .. 10_000_000); -- Fine.
>
> the_Array_2 : access Integer_array
> := new Integer_array' (1 .. 10_000_000 => <>); -- Stack overflow.
>
> begin
> null;
> end;
>
> It seems that, with the initialiser, GNAT is creating the array on
> the stack before copying it to the final heap memory ?
Not sure precisely what the bug is, but something odd is going on.
This is on a Mac with GNAT GPL 2013.
The stack overflow occurs with an array length 2**21 but not 2**20.
The traceback shows it happening at the start of the procedure (line
"procedure bug_Test"). I put the declarations into their own declare
blocks with Put_Lines, and the first never got executed.
I'm not sure what "=> <>" is expected to do when there's no default
value; I added "with Default_Component_Value => 42" to Integer_Array,
and The_Array_1 (0) was 42 but The_Array_2 (1) was unchanged at 0!
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GNAT: Why does a large 'new' allocation blow the stack when an initialiser is present ?
2013-11-01 2:49 GNAT: Why does a large 'new' allocation blow the stack when an initialiser is present ? Rod Kay
2013-11-01 8:45 ` Simon Wright
@ 2013-11-01 10:19 ` sbelmont700
2013-11-01 11:28 ` Rod Kay
1 sibling, 1 reply; 6+ messages in thread
From: sbelmont700 @ 2013-11-01 10:19 UTC (permalink / raw)
On Thursday, October 31, 2013 10:49:20 PM UTC-4, Rod Kay wrote:
> It seems that, with the initialiser, GNAT is creating the array on the stack before copying it to the final heap memory ?
Don't necessarily assume they are on the heap. Allocators of anonmous access types work differently than those of named types. They are (or at least can be) put on the stack instead of the heap, since they are (or at least can be) reclaimed when the subprogram ends (13.11~25/2).
-sb
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GNAT: Why does a large 'new' allocation blow the stack when an initialiser is present ?
2013-11-01 8:45 ` Simon Wright
@ 2013-11-01 11:23 ` Rod Kay
2013-11-01 15:04 ` Georg Bauhaus
1 sibling, 0 replies; 6+ messages in thread
From: Rod Kay @ 2013-11-01 11:23 UTC (permalink / raw)
On Friday, 1 November 2013 19:45:51 UTC+11, Simon Wright wrote:
>
> I'm not sure what "=> <>" is expected to do when there's no default
>
> value; I added "with Default_Component_Value => 42" to Integer_Array,
>
> and The_Array_1 (0) was 42 but The_Array_2 (1) was unchanged at 0!
Howdy,
Yes, somewhat odd. I'd thought (well, assumed) that if <> was used and no default value exists, then no initialisation takes place.
I also tried ...
:= new Integer_array' (1 .. 10_000_000 => 5);
... tho with no change in the result.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GNAT: Why does a large 'new' allocation blow the stack when an initialiser is present ?
2013-11-01 10:19 ` sbelmont700
@ 2013-11-01 11:28 ` Rod Kay
0 siblings, 0 replies; 6+ messages in thread
From: Rod Kay @ 2013-11-01 11:28 UTC (permalink / raw)
On Friday, 1 November 2013 21:19:01 UTC+11, sbelm...@gmail.com wrote:
>
> Don't necessarily assume they are on the heap. Allocators of anonymous access types work differently than those of named types. They are (or at least can be) put on the stack instead of the heap, since they are (or at least can be) reclaimed when the subprogram ends (13.11~25/2).
>
Ah, thanks for the info, I was not aware of this.
I changed the test code to use a named access type, tho it hasn't appeared to change the result.
type Integer_array is array (Integer range <>) of Integer;
type access_Integer_array is access Integer_array;
the_Array_1 : access_Integer_array
:= new Integer_array (1 .. 10_000_000); -- Fine.
the_Array_2 : access_Integer_array
:= new Integer_array' (1 .. 10_000_000 => 5); -- Stack overflow.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GNAT: Why does a large 'new' allocation blow the stack when an initialiser is present ?
2013-11-01 8:45 ` Simon Wright
2013-11-01 11:23 ` Rod Kay
@ 2013-11-01 15:04 ` Georg Bauhaus
1 sibling, 0 replies; 6+ messages in thread
From: Georg Bauhaus @ 2013-11-01 15:04 UTC (permalink / raw)
On 01/11/13 09:45, Simon Wright wrote:
> Rod Kay <rodakay@internode.on.net> writes:
>
>>
>> procedure bug_Test
>> is
>> type Integer_array is array (Integer range <>) of Integer;
>>
>> the_Array_1 : access Integer_array
>> := new Integer_array (1 .. 10_000_000); -- Fine.
>>
>> the_Array_2 : access Integer_array
>> := new Integer_array' (1 .. 10_000_000 => <>); -- Stack overflow.
>>
>> begin
>> null;
>> end;
>>
>> It seems that, with the initialiser, GNAT is creating the array on
>> the stack before copying it to the final heap memory ?
>
> Not sure precisely what the bug is, but something odd is going on.
Looking at the output of -gnatDG, I see that, for the second array,
a fresh one is simply declared, then initialized in a loop, and only
then an allocator creates the final array from the object just
initialized. I don't know whether this output reflects what the code
actually does, but it seems to agree with the above observations.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-11-01 15:04 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-01 2:49 GNAT: Why does a large 'new' allocation blow the stack when an initialiser is present ? Rod Kay
2013-11-01 8:45 ` Simon Wright
2013-11-01 11:23 ` Rod Kay
2013-11-01 15:04 ` Georg Bauhaus
2013-11-01 10:19 ` sbelmont700
2013-11-01 11:28 ` Rod Kay
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox