GNAT: Why does a large 'new' allocation blow the stack when an initialiser is present ?

GNAT: Why does a large 'new' allocation blow the stack when an initialiser is present ?

[Rod Kay]

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 ?

Re: GNAT: Why does a large 'new' allocation blow the stack when an initialiser is present ?

[Simon Wright]

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!

Re: GNAT: Why does a large 'new' allocation blow the stack when an initialiser is present ?

[Rod Kay]

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.

Re: GNAT: Why does a large 'new' allocation blow the stack when an initialiser is present ?

[Georg Bauhaus]

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.

Re: GNAT: Why does a large 'new' allocation blow the stack when an initialiser is present ?

[sbelmont700]

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

Re: GNAT: Why does a large 'new' allocation blow the stack when an initialiser is present ?

[Rod Kay]

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.