Sorry, looks like I somehow put this in the wrong thread. (thread:
CLIENT_FOUND_ROWS) Maybe a mod. can delete that post?

------

I am developing code that needs to create query objects often. There
seems to be a memory leak - memory not being released by the query
object when it goes out of scope. Is this a known issue, or am I missing
something? I have tried this with VC7.1 and VC8.

code to recreate problem:

// Begin Code
mysqlpp::Connection conn = new mysqlpp::Connection();
for(int i=0; i <1000000; i++)
{
mysqlpp::Query myQuery = conn.query();
}
// End Code


Thanks!

- Bill K.



--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Bill K wrote:
Ahahaha. This is a mail list. I can't delete emails from other
people's inboxes. Theoretically I could remove it from the archives,
but most of the damage has already been done. Live and learn, dude.

I think you've misdiagnosed the problem. I ran your test code on a
Linux box, and the amount of memory stays static throughout the
program's run time. Between this and what I see in the call stack
window when after it crashes, I think it's more likely that the problem
is somewhere down in VC++'s runtime library.

If you're motivated enough, an interesting test would be to revert Query
back to the old style stream mechanism. (See the v2.0.0 ChangeLog
entry.) We couldn't make that reversion permanent, because the old
stream style is obsolete, but it would tell us whether I'm right about
where the problem is. If the symptom changes, it's in the runtime library.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Warren Young wrote:
archive. But ok, you can't; thanks for answering my question. =)
The query object has no leak, tested with the same code. So, it may be
with MS's runtime library like you say.

At first I thought the problem was with MS's known std::basic_iostream
memory leaking problem. ( info here:
http://connect.microsoft.com/VisualS...edbackID=98861
) However, I obtained a non-public hotfix from MS that supposedly fixed
that problem, which it looks like it did, when I test out
std::stringstream and std::iostream objects in a similar loop.

I will look into it some more. Anyone else having similar issues?

Thank you for your help.

- Bill K.


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Bill K wrote:
Sorry if I annoyed you, but the very fact that you asked suggested that
you are more used to web forums, corporate email systems, or other
captive systems. On a public mailing list, you have to assume that once
the message is gone, it's gone.

Indeed. I "own" this project, but I don't have any special access to
the mail servers. You'd have as much chance of success asking MySQL
Inc.'s server admins directly to remove the message as I would.

Uh, okay, I think you're arguing about semantics here. You offered a
hypothesis as to where the problem is, and I told you that I thought you
were wrong, giving evidence to back up my assertion. Is that
distinction in phrasing really worth fighting for?

I'm not sure I understand. Are you saying that the problem is indeed
fixed when you apply the patch, or that it only fixes the case of
creating stream objects but not Query objects?

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Warren Young wrote:
Sorry for the confusion. I am saying that the MS hotfix does not fix the
problem I am having with the query object, like I thought it would. The
MS hotfix fixed the memory leak in basic_iostream (used in fstream and
stringstream, and others) - which I thought may have fixed the query
object since it inherits from ostream. But no. I only mentioned the MS
hotfix so anyone aware of the memory leak in MS's CRT would know I have
a patch for it, so that shouldn't be the problem.

Thanks

- Bill K.


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Bill K wrote:
Okay, thanks for clearing that up.

Okay, but here's another data point for you: I just tried the test
program again, and when it crashes it's only using 5 MB. It can't be a
memory leak.

Here, it's crashing when the CRT dereferences a null pointer. Why the
CRT is doing that is the mystery.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Warren Young wrote:
Crashes, eh? It doesn't crash for me. Adding an "if( !(i%1000) ){
std::cout << i << endl; }" in the loop, I can see it fly through and
finish all million loops, using over 80MB of memory at the end,
according to Windows Task Manager.

I'll have a look at it more tomorrow.

Thanks again.

- Bill


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

To put my penny's worth in, trying it on Visual Studio Express with mysql++
2.0.7 shows the memory usage going up to about 65M as Bill describes (mine
doesn't crash).

However, turning on memory leak detection
(http://msdn.microsoft.com/library/de...-us/vsdebug/ht
ml/vxconenablingmemoryleakdetection.asp) shows no leaks. I even put a
memory leak in the Query constructor and recompiled mysql++. My memory leak
showed up, no other one did.

I'm not sure why the memory usage goes up so high, but it might have
something to do with the fact that the runtime and O/S don't necessarily
return any memory freed up to the general pool straight away (for efficiency
reasons). I also tried increasing the loop size ten fold, and after the
memory usage got up to about 300M on my machine, Windows started reclaiming
the memory and it had dropped to 14M by the end.

I've included the revised test prog below (note, you shouldn't be using new
to assign to the conn object, as that does cause a memory leak).

Regards,

Matt.


#include "stdafx.h"
#include <stdlib.h>
#include <crtdbg.h>
#include "connection.h"
#include "query.h"

void test()
{
printf("starting test\r\n");

mysqlpp::Connection conn; // = new mysqlpp::Connection();

for(int i=0; i <10; i++)
{
mysqlpp::Query myQuery = conn.query();
}

printf("done test\r\n");
}

int _tmain(int argc, _TCHAR* argv[])
{
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

test();

return 0;
}

-----Original Message-----
From: Bill K [mailto:reply (AT) billism (DOT) com]
Sent: 22 June 2006 02:41
To: plusplus (AT) lists (DOT) mysql.com
Subject: Re: Query Object Memory Leak?

Warren Young wrote:
Crashes, eh? It doesn't crash for me. Adding an "if( !(i%1000) ){ std::cout
<< i << endl; }" in the loop, I can see it fly through and finish all
million loops, using over 80MB of memory at the end, according to Windows
Task Manager.

I'll have a look at it more tomorrow.

Thanks again.

- Bill


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:
http://lists.mysql.com/plusplus?unsu...coms (DOT) com


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Matt Dargavel wrote:
I did a similar test, with 100 million loops (no crash). By the time it
got to the 50 millionth loop, its memory usage was up to 692M, but then
started dropping, and it maintained below 25M for the rest of the
iterations, however; the Windows Page File Usage never dropped until the
program ended. PF Usage was up to 1.9G towards the end. When the program
ended, the Page File Usage went back down to about 300M where it was
before the test program started.
(I am running the "release" executable, not the "debug")

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

------=_Part_11176_29404370.1150993251195
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Windows memory reporting tools generally can't be trusted to show actual
usage.

A good example of this is have some program running. Look at the memory
usage in the task manager. Minimize it, then restore it and you'll see the
memory usuage drop dramatically on a lot of occasions.

I think that the task manager type memory tools just look at memory
allocations and don't take into account releases. This is just a guess.

But if you are counting on the memory usage stats in the task manager to
give you an accurate indication of how much memory a program is using,
you'll be very disappointed.

On 6/22/06, Bill K <reply (AT) billism (DOT) com> wrote:
------=_Part_11176_29404370.1150993251195--