Memory leak in GNATcoll or false positive from valgrind?

Memory leak in GNATcoll or false positive from valgrind?

[Thomas Løcke]

Hey all,

I'm using this to connect to my PostgreSQL server:

function Database_Connection_Factory
   (Desc : in GNATCOLL.SQL.Exec.Database_Description)
    return GNATCOLL.SQL.Exec.Database_Connection
is
    use GNATCOLL.SQL.Exec;
    use GNATCOLL.SQL.Postgres;
    DBMS : constant String := Get_DBMS (Desc);
begin
    if DBMS = DBMS_Postgresql then
      return Build_Postgres_Connection (Desc);
    else
      return null;
    end if;
end Database_Connection_Factory;

declare
    DB_Descr : GNATCOLL.SQL.Exec.Database_Description;
    DB : SQL.Exec.Database_Connection;
    C1 : SQL.Exec.Forward_Cursor;
begin
    GNATCOLL.SQL.Exec.Setup_Database
      (Description   => DB_Descr,
       Database      => "my_database",
       User          => "my_user",
       Host          => "my_host",
       Password      => "my_password",
       DBMS          => GNATCOLL.SQL.Exec.DBMS_Postgresql,
       SSL           => GNATCOLL.SQL.Exec.Prefer);

    DB := GNATCOLL.SQL.Exec.Get_Task_Connection
      (Description  => DB_Descr,
       Factory      => Database_Connection_Factory'Access);

    C1.Fetch (Connection => DB,
              Query      => "select * from some_table");
    while C1.Has_Row loop
      Put_Line (C1.Value (Field => 1));
      C1.Next;
    end loop;

    DB1.Commit_Or_Rollback;
end;

And it is working a charm, except that valgrind is reporting a leak when
I'm running it: http://pastebin.com/z66U5YAQ

I can make the leak go away, if I call Get_Task_Connection from a dummy
DB connection task that looks like this:

task body DB_Conn
is
    use GNATCOLL.SQL.Exec;
begin
    loop
       select
          accept Fetch (Conn : out Database_Connection;
                        Desc : in Database_Description) do
             Conn := Get_Task_Connection
               (Description  => Desc,
                Factory      => Database_Connection_Factory'Access);
          end Fetch;
       or
          terminate;
       end select;
    end loop;
end DB_Conn;

A mapping between the AWS tasks and the DB_Conn tasks are kept using the
Ada.Task_Attributes package:

package Task_Association is new Ada.Task_Attributes
   (DB_Conn_Access, null);

This works, without a hitch. No leaks. Instead I get the annoying extra
DB_Conn layer. I'd much rather just go straight to Get_Task_Connection
from my AWS thread.

So, is this valgrind reporting a false positive, or am I doing something
wrong?

The above happens with GNATcoll (gnatlib) SVN revision 169867.

-- 
Thomas L�cke

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

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

[Thomas Løcke]

Same leak, now on a 32 bit platform: http://pastebin.com/iWwGYXB7

-- 
Thomas L�cke

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

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

[Emmanuel Briot]

> So, is this valgrind reporting a false positive, or am I doing something
> wrong?

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).

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

[Thomas Løcke]

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