From: Warren Young
Date: November 28 2007 10:46am
Subject: Re: Is method "const ColData Row::at(size_type i) const"  leaking
 memory?
List-Archive: http://lists.mysql.com/plusplus/7194
Message-Id: <474D46EA.1090109@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thunder0 wrote:
> Actually I have re-done that to be completely sure, and the segmentation
> fault occurred again.

Weird.

If you're still interested in pursuing it, would you try the stuff in 
svn?  I've done a few things recently which _may_ change what you're seeing.

One is the way ResUse/Result handles its memory.  It was very tricksy, 
and while I'm fairly sure it was still correct, I can see how it could 
leak in the "right" circumstances.

Another is that ColData's memory management has been totally redesigned 
in v3, so it's possible that there was a real bug but it got 
accidentally killed by collateral damage, instead of on purpose.

Yet other possibility is that Connection now provides thread_end(): call 
it from each thread that uses MySQL++ to release the per-thread memory 
allocated by the C API library.  If you weren't already calling 
mysql_thread_end() (which this just wraps), you should be seeing a 
"leak" here, but it's not what you're reporting, so I don't see that 
this is on point here.  More details on this issue and why I put "leak" 
in quotes here:

	http://tangentsoft.net/mysql++/#memleak

What's in svn right now is my work towards v3, and it's a major upgrade, 
so don't do this if you can't afford to change your code to make it 
compatible.  None of the API changes in MySQL++ v3 are gratuitous, so 
it's possible your code will work without changes, but I wouldn't bet on 
it.  There's just too much that's different now.