Error: allocation from empty storage pool

Error: allocation from empty storage pool

[Alejandro R. Mosteo]

In a library I'm trying to have all allocations done from user-specified 
storage pools. There is no restriction on using the heap, as long as it 
comes from a user pool (that can default to the regular heap, of course).

The idea was then to use "pragma Default_Storage_Pool (null)" at the 
library root to ensure no use of default allocators, and wherever needed 
provide facilities to get a pool from the user.

However, this test fails:

---8<---

pragma Restrictions (No_Secondary_Stack); -- Just to be sure in this ex.
pragma Default_Storage_Pool (null);

procedure Anon is

    type Holder is record
       I : aliased Integer;
    end record;

    type Ref (Elem : access constant Integer) is limited null record;

    function To_Ref (Hold : aliased Holder) return Ref is
      (Elem => Hold.I'Access); -- Error in subject here

begin
    null;
end Anon;

---8<---

There's actually no allocation being made, and I could have a Holder 
variable in the stack, and take a reference, and still no pool would be 
used at all.

So it seems this pragma is too naïve. To make it into questions:

Is this the pragma expected behavior or a particularity of gnat? Is the 
approach reasonable? This is my first attempt at working in a 
"restricted" Ada environment so I don't really have a clear idea of the 
preferred way to do what I want. Also, I'd like if possible to avoid 
making everything generic on the user pool.

Thanks,
Álex.

Re: Error: allocation from empty storage pool

[Simon Wright]

"Alejandro R. Mosteo" <alejandro@mosteo.com> writes:

> In a library I'm trying to have all allocations done from
> user-specified storage pools. There is no restriction on using the
> heap, as long as it comes from a user pool (that can default to the
> regular heap, of course).
>
> The idea was then to use "pragma Default_Storage_Pool (null)" at the
> library root to ensure no use of default allocators, and wherever
> needed provide facilities to get a pool from the user.
>
> However, this test fails:
>
> ---8<---
>
> pragma Restrictions (No_Secondary_Stack); -- Just to be sure in this ex.
> pragma Default_Storage_Pool (null);
>
> procedure Anon is
>
>    type Holder is record
>       I : aliased Integer;
>    end record;
>
>    type Ref (Elem : access constant Integer) is limited null record;
>
>    function To_Ref (Hold : aliased Holder) return Ref is
>      (Elem => Hold.I'Access); -- Error in subject here
>
> begin
>    null;
> end Anon;
>
> ---8<---
>
> There's actually no allocation being made, and I could have a Holder
> variable in the stack, and take a reference, and still no pool would
> be used at all.
>
> So it seems this pragma is too naïve. To make it into questions:
>
> Is this the pragma expected behavior or a particularity of gnat? Is
> the approach reasonable? This is my first attempt at working in a
> "restricted" Ada environment so I don't really have a clear idea of
> the preferred way to do what I want. Also, I'd like if possible to
> avoid making everything generic on the user pool.

I'm 99% confident this is a bug in GNAT.

The repreentation of the generated code (-gnatG) for To_Ref is

   function to_ref (hold : aliased holder; to_refBIPalloc : natural;
     to_refBIPstoragepool :
     system__storage_pools__root_storage_pool_ptr; to_refBIPaccess :
     T5b) return ref is
   begin
      R14b : declare
         [subtype T12b is ref (hold.i'access)]
         type A16b is access all T12b;
         R17b : A16b := null;
         if to_refBIPalloc = 1 then
            R17b := A16b!(to_refBIPaccess);
         elsif to_refBIPalloc = 2 then
            R17b := new T12b[storage_pool =
              system__secondary_stack__ss_pool];
         elsif to_refBIPalloc = 3 then
            R17b := new T12b;
         elsif to_refBIPalloc = 4 then
            P15b : system__storage_pools__root_storage_pool renames
              to_refBIPstoragepool.all;
            R17b := new T12b[storage_pool = P15b];
         else
            [program_error "build in place mismatch"]
         end if;
         R13b : T12b renames R17b.all;
         R13b.elem := hold.i'access;
      begin
         return R13b;
      end R14b;
   end to_ref;

where to_refBIPalloc is a parameter determined by the compiler. In the
case of

   H : aliased Holder := (I => 42);
   R : Ref := To_Ref (H);

it's 1, and to_refBIPaccess is R'Unrestricted_Access.

The other cases are presumably to cope with other calling patterns
(can't imagine what), and in particular case 3 is a standard 'new',
which would be what triggers the error message.

Re: Error: allocation from empty storage pool

[Alejandro R. Mosteo]

On 12/07/2018 13:41, Simon Wright wrote:
> "Alejandro R. Mosteo" <alejandro@mosteo.com> writes:
> 
>> In a library I'm trying to have all allocations done from
>> user-specified storage pools. There is no restriction on using the
>> heap, as long as it comes from a user pool (that can default to the
>> regular heap, of course).
>>
>> The idea was then to use "pragma Default_Storage_Pool (null)" at the
>> library root to ensure no use of default allocators, and wherever
>> needed provide facilities to get a pool from the user.
>>
>> However, this test fails:
>>
>> ---8<---
>>
>> pragma Restrictions (No_Secondary_Stack); -- Just to be sure in this ex.
>> pragma Default_Storage_Pool (null);
>>
>> procedure Anon is
>>
>>     type Holder is record
>>        I : aliased Integer;
>>     end record;
>>
>>     type Ref (Elem : access constant Integer) is limited null record;
>>
>>     function To_Ref (Hold : aliased Holder) return Ref is
>>       (Elem => Hold.I'Access); -- Error in subject here
>>
>> begin
>>     null;
>> end Anon;
>>
>> ---8<---
>>
>> There's actually no allocation being made, and I could have a Holder
>> variable in the stack, and take a reference, and still no pool would
>> be used at all.
>>
>> So it seems this pragma is too naïve. To make it into questions:
>>
>> Is this the pragma expected behavior or a particularity of gnat? Is
>> the approach reasonable? This is my first attempt at working in a
>> "restricted" Ada environment so I don't really have a clear idea of
>> the preferred way to do what I want. Also, I'd like if possible to
>> avoid making everything generic on the user pool.
> 
> I'm 99% confident this is a bug in GNAT.

Thanks for the analysis, that's a neat way of seeing what's going on. I 
guess I will report it then.

I was thinking that maybe the pragma works at the access type level 
instead of actual allocations. That is, any access type without 
'Storage_size => 0 or explicit allocator would fail. But reading 13.11.3 
6/3 it seems that it is the other way around: at the point of the access 
type declaration either default 'Storage_Size or 'Storage_Pool is 
determined depending on the Default_Storage_Pool value. Though I am not a 
l-lawyer so...

Álex.

> 
> The repreentation of the generated code (-gnatG) for To_Ref is
> 
>     function to_ref (hold : aliased holder; to_refBIPalloc : natural;
>       to_refBIPstoragepool :
>       system__storage_pools__root_storage_pool_ptr; to_refBIPaccess :
>       T5b) return ref is
>     begin
>        R14b : declare
>           [subtype T12b is ref (hold.i'access)]
>           type A16b is access all T12b;
>           R17b : A16b := null;
>           if to_refBIPalloc = 1 then
>              R17b := A16b!(to_refBIPaccess);
>           elsif to_refBIPalloc = 2 then
>              R17b := new T12b[storage_pool =
>                system__secondary_stack__ss_pool];
>           elsif to_refBIPalloc = 3 then
>              R17b := new T12b;
>           elsif to_refBIPalloc = 4 then
>              P15b : system__storage_pools__root_storage_pool renames
>                to_refBIPstoragepool.all;
>              R17b := new T12b[storage_pool = P15b];
>           else
>              [program_error "build in place mismatch"]
>           end if;
>           R13b : T12b renames R17b.all;
>           R13b.elem := hold.i'access;
>        begin
>           return R13b;
>        end R14b;
>     end to_ref;
> 
> where to_refBIPalloc is a parameter determined by the compiler. In the
> case of
> 
>     H : aliased Holder := (I => 42);
>     R : Ref := To_Ref (H);
> 
> it's 1, and to_refBIPaccess is R'Unrestricted_Access.
> 
> The other cases are presumably to cope with other calling patterns
> (can't imagine what), and in particular case 3 is a standard 'new',
> which would be what triggers the error message.
> 

Re: Error: allocation from empty storage pool

[Randy Brukardt]

"Alejandro R. Mosteo" <alejandro@mosteo.com> wrote in message 
news:pi7gmk$riu$1@dont-email.me...
...
> I was thinking that maybe the pragma works at the access type level 
> instead of actual allocations. That is, any access type without 
> 'Storage_size => 0 or explicit allocator would fail. But reading 13.11.3 
> 6/3 it seems that it is the other way around: at the point of the access 
> type declaration either default 'Storage_Size or 'Storage_Pool is 
> determined depending on the Default_Storage_Pool value. Though I am not a 
> l-lawyer so...

Correct. But note that when Default_Storage_Pool is null, then Storage_Size 
=> 0. When Storage_Size is statically zero, allocators are illegal 
(4.8(5.4/3)), as are calls on instances of Unchecked_Deallocation 
(13.11.2(3.1/3)). It's allowed to declare such types, so that one can use 
'Access to give them values.

I don't see any language reason for an allocator to be used in your example, 
so I concur that there is a GNAT bug involved.

                                          Randy.

Re: Error: allocation from empty storage pool

[Alejandro R. Mosteo]

On 12/07/2018 23:08, Randy Brukardt wrote:
> "Alejandro R. Mosteo" <alejandro@mosteo.com> wrote in message
> news:pi7gmk$riu$1@dont-email.me...
> ...
>> I was thinking that maybe the pragma works at the access type level
>> instead of actual allocations. That is, any access type without
>> 'Storage_size => 0 or explicit allocator would fail. But reading 13.11.3
>> 6/3 it seems that it is the other way around: at the point of the access
>> type declaration either default 'Storage_Size or 'Storage_Pool is
>> determined depending on the Default_Storage_Pool value. Though I am not a
>> l-lawyer so...
> 
> Correct. But note that when Default_Storage_Pool is null, then Storage_Size
> => 0. When Storage_Size is statically zero, allocators are illegal
> (4.8(5.4/3)), as are calls on instances of Unchecked_Deallocation
> (13.11.2(3.1/3)). It's allowed to declare such types, so that one can use
> 'Access to give them values.
> 
> I don't see any language reason for an allocator to be used in your example,
> so I concur that there is a GNAT bug involved.

I reported it yesterday and I just got confirmation that it is a bug.

Thanks,
Álex.

> 
>                                            Randy.
> 
>