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.

6/22/06, Bill K <reply (AT) billism (DOT) comwrote:

Matt Dargavel wrote:
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
(

) 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 /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 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")

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_ALLC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

test();

return 0;
}

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 Memory Leak?

Warren Young wrote:
>
>Bill K wrote:
>>
I am saying that the MS hotfix does not fix the problem I am having
with the query object, like I thought it would.

>, thanks for clearing that up.
>>
>>
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.

>, 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.
>>
>>
>
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