* Memory leak in GNATcoll or false positive from valgrind?
@ 2011-01-29 11:33 Thomas Løcke
2011-01-29 14:34 ` Thomas Løcke
2011-01-30 19:24 ` Emmanuel Briot
0 siblings, 2 replies; 4+ messages in thread
From: Thomas Løcke @ 2011-01-29 11:33 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Memory leak in GNATcoll or false positive from valgrind?
2011-01-29 11:33 Memory leak in GNATcoll or false positive from valgrind? Thomas Løcke
@ 2011-01-29 14:34 ` Thomas Løcke
2011-01-30 19:24 ` Emmanuel Briot
1 sibling, 0 replies; 4+ messages in thread
From: Thomas Løcke @ 2011-01-29 14:34 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Memory leak in GNATcoll or false positive from valgrind?
2011-01-29 11:33 Memory leak in GNATcoll or false positive from valgrind? Thomas Løcke
2011-01-29 14:34 ` Thomas Løcke
@ 2011-01-30 19:24 ` Emmanuel Briot
2011-01-31 7:06 ` Thomas Løcke
1 sibling, 1 reply; 4+ messages in thread
From: Emmanuel Briot @ 2011-01-30 19:24 UTC (permalink / raw)
> 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).
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Memory leak in GNATcoll or false positive from valgrind?
2011-01-30 19:24 ` Emmanuel Briot
@ 2011-01-31 7:06 ` Thomas Løcke
0 siblings, 0 replies; 4+ messages in thread
From: Thomas Løcke @ 2011-01-31 7:06 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-01-31 7:06 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-29 11:33 Memory leak in GNATcoll or false positive from valgrind? Thomas Løcke
2011-01-29 14:34 ` Thomas Løcke
2011-01-30 19:24 ` Emmanuel Briot
2011-01-31 7:06 ` Thomas Løcke
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox