comp.lang.ada
 help / color / mirror / Atom feed
From: "Alejandro R. Mosteo" <alejandro@mosteo.com>
Subject: Re: Memory leak in Indefinite_Holders
Date: Mon, 13 Jun 2016 11:45:36 +0200
Date: 2016-06-13T11:45:36+02:00	[thread overview]
Message-ID: <njlvc0$25k$1@dont-email.me> (raw)
In-Reply-To: <njlqfi$ico$1@dont-email.me>

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.


      reply	other threads:[~2016-06-13  9:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-13  8:22 Memory leak in Indefinite_Holders Alejandro R. Mosteo
2016-06-13  9:45 ` Alejandro R. Mosteo [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox