|List:||MySQL++||« Previous MessageNext Message »|
|From:||Warren Young||Date:||November 28 2007 10:46am|
|Subject:||Re: Is method "const ColData Row::at(size_type i) const" leaking|
|View as plain text|
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.