* Memory leak in Indefinite_Holders
@ 2016-06-13 8:22 Alejandro R. Mosteo
2016-06-13 9:45 ` Alejandro R. Mosteo
0 siblings, 1 reply; 2+ messages in thread
From: Alejandro R. Mosteo @ 2016-06-13 8:22 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Memory leak in Indefinite_Holders
2016-06-13 8:22 Memory leak in Indefinite_Holders Alejandro R. Mosteo
@ 2016-06-13 9:45 ` Alejandro R. Mosteo
0 siblings, 0 replies; 2+ messages in thread
From: Alejandro R. Mosteo @ 2016-06-13 9:45 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-06-13 9:45 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-13 8:22 Memory leak in Indefinite_Holders Alejandro R. Mosteo
2016-06-13 9:45 ` Alejandro R. Mosteo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox