Memory Leaks

[LarryMc]

I'm trying to track down some possible memory leaks in my xml class library.
In doing so I've noticed something unrelated to my lib.

I have a simple window with one menu option which calls a domodal dialog.

I build the dialog GUI right after the program window is created ( so as not to build it each time I call the dialog)

When I start the program it says I'm using 1,520K
As I switch between my program, the memory monitor, and posting this message my programs memory useage keeps creeping up in approx 4k increments until it got to 1,552K and appears stable there.

When I close the domodal dialog I show 1,628K of memory being used after the dialog disappears.
(which is 76K MORE than when the dialog was showing.)
Switching screens doesn't appear to make it increment like above.

If I call the dialog again memory goes up another 4K.

As I switch between my program, the memory monitor, and posting the message my programs memory useage keeps creeping up in approx 4k increments until it got to 1,644K and appears stable there.

When I close the dialog and am back to where I started I show 1,652K of memory being used.
And in the last minute or so of switching screens it is up to 1,664K

I don't understand.

I'm using a free memory monitor called Glarysoft Process Manager 1.3 which works like windows task manager but with better resolution on memory useage.

Could someone who has a good memory monitor see if the program below acts the same way for them.
And if it does act that way then it becomes a question of why.

Code Select Expand

window w1
dialog d1
string filter,basepath
const MM_New = 1
OPENWINDOW w1,0,0,900,700,0x80CA0080,0,"memory leak test",&w1_main
BEGINMENU w1   
menutitle "Project"
menuitem "New             ", 0, MM_New
endmenu
CREATEDIALOG d1,0,0,393,272,0x80C80080,0,"EB INC Decoder",&Handler
CONTROL d1,@BUTTON,"Close",241,196,70,20,0x50000001,7

CENTERWINDOW w1
waituntil w1=0

end

sub w1_main
SELECT @MESSAGE
CASE @IDCLOSEWINDOW
CLOSEWINDOW w1
    CASE @IDINITDIALOG
        CENTERWINDOW w1

CASE @IDMENUPICK
SELECT @MENUNUM
Case MM_NEW
domodal(d1,w1)
default
endselect
default
endselect
return
endsub

sub Handler
select @CLASS
case @IDINITDIALOG
centerwindow d1
case @IDCONTROL
select @CONTROLID
case 7:'cancel
CloseDialog d1,@IDCANCEL
default
endselect
endselect
return
endsub


[REDEBOLT]

Larry,

I dl'd the memory monitor and it showed the same results as WTG.
Here are the results of my testing.
I think you are simply seeing the results of windows fragmenting of ram.

Code Select Expand

7:44 PM 7/12/2007
started at 3144

7:45 PM 7/12/2007
now at 3224

7:45 PM 7/12/2007
select project
3268

7:46 PM 7/12/2007
select new
3308

7:49 PM 7/12/2007
bounced around internet
3308

7:50 PM 7/12/2007
back to decoder
3316

7:51 PM 7/12/2007
closed dialog
3332

7:51 PM 7/12/2007
project/new
3336

7:52 PM 7/12/2007
closed dialog
3336

7:53 PM 7/12/2007
project/new
3336

7:54 PM 7/12/2007
closed dialog
3336

7:56 PM 7/12/2007
after several more cycles
it appeared steady at 3336

7:58 PM 7/12/2007
rerun - held steady at 3348

8:00 PM 7/12/2007
rerun - started at 3152
held steady at 3356



[LarryMc]

So I guess my question now is how do I find a memory leak in a much more sophisticated and larger program when normal operation jumps around and varies like that?

Larry
Edit: BTW, thanks Bob for checking for me.

[REDEBOLT]

YW Larry.

If the overall ram usage reverts back to what it was before the program ran, then I don't think you have a problem.  The problem is when it doesn't.  If the WTM shows progressive increments in ram over time, then it is a problem.  I didn't see that happening.

[LarryMc]

I'm running my big program w/my xml lib right now to check that out.  Lot of paths through the program so it takes a while to get an idea.

Thanks again for taking the time to look at it.

Larry