From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,b6c392d1e6028229
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII
Path: 
 g2news1.google.com!news1.google.com!news.glorb.com!dotsrc.org!filter.dotsrc.org!news.dotsrc.org!not-for-mail
Date: Mon, 31 Jan 2011 08:06:42 +0100
From: =?ISO-8859-1?Q?Thomas_L=F8cke?= <tl@ada-dk.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.13) Gecko/20101210 Thunderbird/3.1.7
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Memory leak in GNATcoll or false positive from valgrind?
References: <4d43fb20$0$23765$14726298@news.sunsite.dk>
 <bb467886-b34b-4f99-aa51-70cba6c441aa@33g2000pru.googlegroups.com>
In-Reply-To: 
 <bb467886-b34b-4f99-aa51-70cba6c441aa@33g2000pru.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <4d465f82$0$23761$14726298@news.sunsite.dk>
Organization: SunSITE.dk - Supporting Open source
NNTP-Posting-Host: 83.91.213.86
X-Trace: news.sunsite.dk
 DXC=>\<_BK9DFb]jXN@]UnT6J_YSB=nbEKnk[[R[7PZBi8o^1GQX8;5?CnWRED9SjB8:6YQo^8G8>And]WMERfe<eT?QFQniZF161`Q
X-Complaints-To: staff@sunsite.dk
Xref: g2news1.google.com comp.lang.ada:16807
Date: 2011-01-31T08:06:42+01:00
List-Id: <comp.lang.ada>

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