Memory leak in Indefinite_Holders

Memory leak in Indefinite_Holders

[Alejandro R. Mosteo]

I think this is a bug in Gnat, but I'd like to hear some other opinion 
before submitting it.

Context: Using Constant_Reference of a holder type embedded in another 
record causes a memory leak.

Self-contained procedure and Valgrind output below:

---8<---

with Ada.Containers.Indefinite_Holders;
with Ada.Text_IO; use Ada.Text_IO;

procedure Holder_Leak is
    use Ada.Containers;
    type Indef is array (Integer range <>) of Integer;
    package Holders is new Indefinite_Holders (Indef);
    type Def is new Holders.Holder with null record;

    -- This wrapper type is necessary for the leak to manifest
    type Outer is record
       Inner : Def;
    end record;

    procedure Eat (O : Outer) is
    begin
       for I of O.Inner.Constant_Reference loop
       -- Using .Element instead there is no leak
          Put_Line (I'Img);
       end loop;
    end Eat;

begin
    for I in 1 .. 666 loop
       Eat ((Inner => To_Holder ((1, 2, 3, 4, 5))));
    end loop;
end Holder_Leak;

---8<---

Curiously, line 17 which is necessary for the leak to occur doesn't show 
in the Valgrind output. The leak is real though, as can be confirmed by 
making the loop infinite and monitoring the process memory usage with 
e.g. top.

Compiled with switches:
  -g -gnatwal.fF -gnatVa -g -O2 -gnato -fstack-check -gnata -gnatf 
-gnat12 -gnatyO

$ valgrind --leak-check=full ./holder_leak

==23853==
==23853== HEAP SUMMARY:
==23853==     in use at exit: 34,632 bytes in 1,332 blocks
==23853==   total heap usage: 2,664 allocs, 1,332 frees, 69,264 bytes 
allocated
==23853==
==23853== 34,632 (15,984 direct, 18,648 indirect) bytes in 666 blocks 
are definitely lost in loss record 2 of 2
==23853==    at 0x4C2DB8F: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23853==    by 0x4177AC: __gnat_malloc (in 
/home/jano/local/rxada/obj/holder_leak)
==23853==    by 0x404A6E: holder_leak__holders__to_holder.3633 
(a-coinho.adb:444)
==23853==    by 0x405FC7: _ada_holder_leak (holder_leak.adb:25)
==23853==    by 0x4028C9: main (b__holder_leak.adb:254)
==23853==
==23853== LEAK SUMMARY:
==23853==    definitely lost: 15,984 bytes in 666 blocks
==23853==    indirectly lost: 18,648 bytes in 666 blocks
==23853==      possibly lost: 0 bytes in 0 blocks
==23853==    still reachable: 0 bytes in 0 blocks
==23853==         suppressed: 0 bytes in 0 blocks
==23853==
==23853== For counts of detected and suppressed errors, rerun with: -v
==23853== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Álex.

Re: Memory leak in Indefinite_Holders

[Alejandro R. Mosteo]

On 13/06/16 10:22, Alejandro R. Mosteo wrote:
> I think this is a bug in Gnat, but I'd like to hear some other opinion
> before submitting it.

I've now tested it using Indefinite_Doubly_Linked_Lists and the leak 
goes away.

Álex.

> Context: Using Constant_Reference of a holder type embedded in another
> record causes a memory leak.
>
> Self-contained procedure and Valgrind output below:
>
> ---8<---
>
> with Ada.Containers.Indefinite_Holders;
> with Ada.Text_IO; use Ada.Text_IO;
>
> procedure Holder_Leak is
>     use Ada.Containers;
>     type Indef is array (Integer range <>) of Integer;
>     package Holders is new Indefinite_Holders (Indef);
>     type Def is new Holders.Holder with null record;
>
>     -- This wrapper type is necessary for the leak to manifest
>     type Outer is record
>        Inner : Def;
>     end record;
>
>     procedure Eat (O : Outer) is
>     begin
>        for I of O.Inner.Constant_Reference loop
>        -- Using .Element instead there is no leak
>           Put_Line (I'Img);
>        end loop;
>     end Eat;
>
> begin
>     for I in 1 .. 666 loop
>        Eat ((Inner => To_Holder ((1, 2, 3, 4, 5))));
>     end loop;
> end Holder_Leak;
>
> ---8<---
>
> Curiously, line 17 which is necessary for the leak to occur doesn't show
> in the Valgrind output. The leak is real though, as can be confirmed by
> making the loop infinite and monitoring the process memory usage with
> e.g. top.
>
> Compiled with switches:
>   -g -gnatwal.fF -gnatVa -g -O2 -gnato -fstack-check -gnata -gnatf
> -gnat12 -gnatyO
>
> $ valgrind --leak-check=full ./holder_leak
>
> ==23853==
> ==23853== HEAP SUMMARY:
> ==23853==     in use at exit: 34,632 bytes in 1,332 blocks
> ==23853==   total heap usage: 2,664 allocs, 1,332 frees, 69,264 bytes
> allocated
> ==23853==
> ==23853== 34,632 (15,984 direct, 18,648 indirect) bytes in 666 blocks
> are definitely lost in loss record 2 of 2
> ==23853==    at 0x4C2DB8F: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==23853==    by 0x4177AC: __gnat_malloc (in
> /home/jano/local/rxada/obj/holder_leak)
> ==23853==    by 0x404A6E: holder_leak__holders__to_holder.3633
> (a-coinho.adb:444)
> ==23853==    by 0x405FC7: _ada_holder_leak (holder_leak.adb:25)
> ==23853==    by 0x4028C9: main (b__holder_leak.adb:254)
> ==23853==
> ==23853== LEAK SUMMARY:
> ==23853==    definitely lost: 15,984 bytes in 666 blocks
> ==23853==    indirectly lost: 18,648 bytes in 666 blocks
> ==23853==      possibly lost: 0 bytes in 0 blocks
> ==23853==    still reachable: 0 bytes in 0 blocks
> ==23853==         suppressed: 0 bytes in 0 blocks
> ==23853==
> ==23853== For counts of detected and suppressed errors, rerun with: -v
> ==23853== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
>
> Álex.