Re: Memory leak in GNATcoll or false positive from valgrind?

["Thomas Løcke" <tl@ada-dk.org>]

On 2011-01-30 20:24, Emmanuel Briot wrote:
> Depends on your point of view.
> You have to somehow call GNATCOLL.SQL.Exec.Free (Database_Connection)
> if you properly want to release the memory. Or you can setup valgrind
> so that it ignores this "leak" (not really a leak, just some memory
> that is automatically freed when the process goes away, but memory
> usage does not grow up as your program lives).


Hey Emmanuel,

So why does the "leak" go away if wrap the Get_Task_Connection in task
instead of calling it directly from an AWS thread?

This gets rid of the leak:

declare
    A_Connection   : GNATCOLL.SQL.Exec.Database_Connection;
    A_DB_Task      : DB_Conn_Access; --  access to the wrapper task
begin
    A_DB_Task := Task_Association.Value;

    if A_DB_Task = Null_DB_Conn_Access then
       A_DB_Task := new DB_Conn;
       Task_Association.Set_Value (Val => A_DB_Task);
    end if;

    A_DB_Task.Fetch (Conn => A_Connection,
                     Desc => DB_Description);

    return A_Connection;
end;

In the above case, the call the Get_Task_Connection is done in the
A_DB_Task.Fetch call. I fail at seeing why this little work-around
fixes the leak.

Also this is the comment for the GNATCOLL.SQL.Exec.Free procedure:

--  Free memory associated with description.
--  This should only be called when the last database connection was
--  closed since each connection keeps a handle on the description

When I'm using Get_Task_Connection I don't plan on closing the database
connections. They should all stay active for the entire lifetime of the
server. So calling Free is not really an option.

But I understand that it's not an actual leak that's happening here, so
I'm no longer worrying as much about it.  :o)

Thanks. And thanks for GNATcoll. It's an awesome piece of work.

-- 
Thomas L�cke

Email: tl at ada-dk.org
Web: http//:ada-dk.org
http://identi.ca/thomaslocke