From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: "Alejandro R. Mosteo" <alejandro@mosteo.com>
Newsgroups: comp.lang.ada
Subject: Re: Memory leak in Indefinite_Holders
Date: Mon, 13 Jun 2016 11:45:36 +0200
Organization: A noiseless patient Spider
Message-ID: <njlvc0$25k$1@dont-email.me>
References: <njlqfi$ico$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 13 Jun 2016 09:45:36 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="df6c13c4617621ca1de5ec657b563bf1";
	logging-data="2228"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+tmaJFppUYyYa9qB/+f4he"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.8.0
In-Reply-To: <njlqfi$ico$1@dont-email.me>
Cancel-Lock: sha1:vYOQrS+M3Mr87+ysSPkcKigoP7M=
Xref: news.eternal-september.org comp.lang.ada:30712
Date: 2016-06-13T11:45:36+02:00
List-Id: <comp.lang.ada>

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.