gnatcoll ORM memory leak

gnatcoll ORM memory leak

[landgraf]

Hi all. 

I'm playing with ORM in gnatcoll. Compile and run sample application [1]. 
And check valgrind report [2]. 
Did I forget call some free methods?


[1]
--==== main.adb ====--
with ORM; use ORM;
with GNATCOLL.SQL.Sessions; use GNATCOLL.SQL.Sessions;
with GNATCOLL.SQL.Sqlite;
procedure Main is 
    Session : Session_Type; 
begin
    GNATCOLL.SQL.Sessions.Setup
        (Descr  => GNATCOLL.SQL.Sqlite.Setup ("db/gnatleak.db"),
    Weak_Cache => True,
    Max_Sessions => 9);
    Session := Get_new_Session;
    for i in 1..100 loop
        declare
            Ob : Detached_Ob'Class := New_Ob;
        begin
                Ob := New_Ob;
                Ob.Set_Name("myname" & I'Img);
                Session.Persist(Ob);
        end; 
    end loop;
    Session.Commit;
    Free;
end Main;

--=== dbmodel ===--
|TABLE                  | ob
| id                    | AUTOINCREMENT | PK ||| 
|name                   | Text          |NOT NULL     |||


[2]
==31208== 3,200 bytes in 100 blocks are definitely lost in loss record 56 of 57
==31208==    at 0x4C2A87C: malloc (vg_replace_malloc.c:270)
==31208==    by 0x6B55BB7: __gnat_malloc (s-memory.adb:92)
==31208==    by 0x6B70E41: system__pool_global__allocate (s-pooglo.adb:61)
==31208==    by 0x6B810E8: system__storage_pools__subpools__allocate_any_controlled (s-stposu.adb:239)
==31208==    by 0x53A1F3A: gnatcoll__sql__sessions__add_to_cache (gnatcoll-sql-sessions.adb:676)
==31208==    by 0x53A29A0: gnatcoll__sql__sessions__persist (gnatcoll-sql-sessions.adb:666)
==31208==    by 0x40BBD2: _ada_main (in /home/pavel/projects/gnatleak/bin/main)
==31208==    by 0x40CC0B: main (in /home/pavel/projects/gnatleak/bin/main)
==31208== 
==31208== LEAK SUMMARY:
==31208==    definitely lost: 3,200 bytes in 100 blocks
==31208==    indirectly lost: 0 bytes in 0 blocks
==31208==      possibly lost: 0 bytes in 0 blocks
==31208==    still reachable: 6,120 bytes in 58 blocks
==31208==         suppressed: 0 bytes in 0 blocks
==31208== Reachable blocks (those to which a pointer was found) are not shown.
==31208== To see them, rerun with: --leak-check=full --show-reachable=yes
==31208== 

Re: gnatcoll ORM memory leak

[Jeffrey Carter]

On 04/26/2013 02:49 PM, landgraf wrote:
>          declare
>              Ob : Detached_Ob'Class := New_Ob;
>          begin
>                  Ob := New_Ob;

Did you intend to call New_Ob twice and discard the result of the 1st call?

-- 
Jeff Carter
"My legs are gray, my ears are gnarled, my eyes are old and bent."
Monty Python's Life of Brian
81

Re: gnatcoll ORM memory leak

[landgraf]

On Saturday, 27 April 2013 03:27:28 UTC+2, Jeffrey Carter  wrote:
> On 04/26/2013 02:49 PM, landgraf wrote:
> 
> >          declare
> 
> >              Ob : Detached_Ob'Class := New_Ob;
> 
> >          begin
> 
> >                  Ob := New_Ob;
> 
> 
> 
> Did you intend to call New_Ob twice and discard the result of the 1st call?
> 
> 
> 
> -- 
> 
> Jeff Carter
> 
> "My legs are gray, my ears are gnarled, my eyes are old and bent."
> 
> Monty Python's Life of Brian
> 
> 81
Yes, It' s my mistake in the reproducer. But there is not second "New" call in the original code.

Changed to:
    for i in 1..100 loop
        declare
            Ob : Detached_Ob'Class := New_Ob;
        begin
                Ob.Set_Name("myname" & I'Img);
                Session.Persist(Ob);
        end; 
    end loop;

But without resolt:
==1388==    definitely lost: 3,200 bytes in 100 blocks

Re: gnatcoll ORM memory leak

[Simon Wright]

landgraf <pavel.y.zhukov@gmail.com> writes:

> ==31208== by 0x53A29A0: gnatcoll__sql__sessions__persist
> (gnatcoll-sql-sessions.adb:666)
> ==31208==    by 0x40BBD2: _ada_main (in /home/pavel/projects/gnatleak/bin/main)
> ==31208==    by 0x40CC0B: main (in /home/pavel/projects/gnatleak/bin/main)

I see that you get line numbers from the gnatcoll library code, but not
your own. Did you build with -g (debug)?

Re: gnatcoll ORM memory leak

[landgraf]

On Saturday, 27 April 2013 08:27:56 UTC+2, Simon Wright  wrote:
> I see that you get line numbers from the gnatcoll library code, but not
> 
> your own. Did you build with -g (debug)?

Yes, I did. 


$ make debug 
rm -rf bin/ obj/ lib/
gprbuild -p -f -gnat12 -P gnat/gnatleak  -gnata -ggdb -g
... omitted ...
gcc -c -gnat12 -gnata -ggdb -g main.adb
... omitted ...
gcc main.o -o main

$ valgrind --leak-check=full ./bin/main 
.... omitted ....
==1721== HEAP SUMMARY:
==1721==     in use at exit: 9,320 bytes in 158 blocks
==1721==   total heap usage: 5,398 allocs, 5,240 frees, 1,063,539 bytes allocated
==1721== 
==1721== 3,200 bytes in 100 blocks are definitely lost in loss record 56 of 57
==1721==    at 0x4C2A87C: malloc (vg_replace_malloc.c:270)
==1721==    by 0x6B55BB7: __gnat_malloc (s-memory.adb:92)
==1721==    by 0x6B70E41: system__pool_global__allocate (s-pooglo.adb:61)
==1721==    by 0x6B810E8: system__storage_pools__subpools__allocate_any_controlled (s-stposu.adb:239)
==1721==    by 0x53A1F3A: gnatcoll__sql__sessions__add_to_cache (gnatcoll-sql-sessions.adb:676)
==1721==    by 0x53A29A0: gnatcoll__sql__sessions__persist (gnatcoll-sql-sessions.adb:666)
==1721==    by 0x40BB36: _ada_main (main.adb:19)
==1721==    by 0x40CA93: main (b__main.adb:700)
==1721== 
==1721== LEAK SUMMARY:
==1721==    definitely lost: 3,200 bytes in 100 blocks
==1721==    indirectly lost: 0 bytes in 0 blocks
==1721==      possibly lost: 0 bytes in 0 blocks
==1721==    still reachable: 6,120 bytes in 58 blocks
==1721==         suppressed: 0 bytes in 0 blocks
==1721== Reachable blocks (those to which a pointer was found) are not shown.
==1721== To see them, rerun with: --leak-check=full --show-reachable=yes
==1721== 
==1721== For counts of detected and suppressed errors, rerun with: -v
==1721== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)