Hey all, I'm wondering if anyone knows of any utilities that might help me find a memory leak ? I've written this little app, and it's got a really serious leak problem. It's not an infamous GDI leak , i'm not doing and manual gdi, it's also not an alloc/dealloc mismatch, i'm not doing any manual alloc/deaalloc. I've even tried using
at regular intervals, formatting the result and throwing it to the console, but the results from this API call still say something like 49% of resources free right up till when my program & windows itself crash because there's no ram left :/ I'm really stumped & will most likely just rewrite the program from scratch tonight when I get home, but the point is, I'd still like a nice little program that'll report memory leaks etc. nice possibility : a debug program that reports on memory allocated by program everytime a breakpoint is hit. is there anything like this out there ??? Thanks Clive [ Entro-P ]
Posted on 2001-03-22 00:10:00 by Entro-P
Entro, Well, just how do you alloc memory? Seems you already know the nice trick of tossing up a console window to emit debug info for a windows app. You can also start the app from an existing DOS box, and pipe that output for later study. So, take your choice of alloc APIs, wrap it in a macro to report alloc and deallocs. You might want to do this one type at a time, as I've seen your app and it just might use a ton of memory bits ;-) You can also have a global variable inc for allocs, dec for deallocs. At program termination, print the value. That gives you a gross count of leaks. Just a few top of the head ideas. :-) --------------------------------------- "Always remember that youíre representing your country. I guess what Iím saying is, donít mess up France the way you messed up your room."
Posted on 2001-03-22 01:01:00 by Ernie
how do i alloc ? I DONT all my data is fixed and explicitly defined in either
used when large amounts required. yes at first I had allocs/deallocs (using
but all of those where removed piece by piece when i started to look for the leak :/ now i have no allocs/deallocs or manuall GDI, and as far as i can tell there shouldn't be any leaks whatsoever, the only thing i am doing with some form of regularity, is the following : createwindow reassign toolbar parent --> created window destoy rebar band ..... then ..... create rebar band reassign toolbar parent --> created band close window ... the program i've written subclasses the rebar control, and makes the toolbars dockable. everything works fine except the leak :/ ah well, i'll just start again tonight when i get home, and watch the momory closely from the start
Posted on 2001-03-22 02:12:00 by Entro-P
Hi, In win32 asm, it is quite hard to start to commit more memory than is availible. Your app starts off with 4GB of (virtual) space, everybody knows that. That memory however is not phyical memory (hence the Virtual bit), but is actualy mapped to phyical memory by the processor co-operating with windows. So in fact, if you allocate say, 100MB of mem on a 32MB system, the allocation will succeed! ___But the only memory that is allocated, is virtual memory___ When you acess your allocated memory, it is 'paged' in and out, by windows, back and forth to your hard disk, so the actual amount of RAM you use is determind by windows. Windows can crash, if it has to much work to do with the paging, and it begins to get behind itself. Really this should not be possible, but windows is windows. What your app sounds like it is doing, is upsetting windows some other way (Upseting windows is not a hard thing to do). Thus causing it to crash. This can be for many reasons, the best way is to track down where the crash occours in your program code, stick a message box or two in, to track your code, and try to figure out why the code is causing the error etc.
Posted on 2001-03-22 05:14:00 by George
I had some aweful effects like you, where the system allocates resources and does not release them. I think, critical are all types of file operations, very critical is the usage of multimedia services, like MCI or ActiveMovie. Another source of dirty and f***ing code is ODBC, which has a lot of leaks. A nice tool for checking leaks is MemProof, it can be found (I hope so) under www.poboxes.com/astoyanov/index.htm beaster. (explative deleted) This message was edited by Ernie, on 3/23/2001 3:35:05 AM
Posted on 2001-03-22 09:48:00 by beaster
I too have had simular problems, and still am baffled how they have appeared. I wrote a small graphical program using GDI arc and pie functions, and masm32 circle function (which uses arc). I made use of no global/local alloc's in the program, and destroyed all objects created in the paint proc. The only maybe unconventional thing i did do was create 8 structures in .data? and filled them for use with an init proc. I know the 8 structure occupy ~ 3KB of memory. And thats it. the rest is alot of conditionals etc. with POINT's and RECT's. Some how i used up 256MB or ram after an evenings work (compiling, testing, and re-compiling..) I personally am unsure if its the program i made, or if it is the program compiling it (Ultra Edit v8). I have used Ultra Edit for everything and havent seen such a problem before, but then again, i also havent compiled so much in one evening before as well. Is it possible that windows doesnt clean up .data? properly, and the fact we dont see this is because most of the time .data? hold a few bytes for handles etc, and never really amounts to an observable difference compared to most ram sizes today? Unless we run our programs millions of times over since ram is mesured by the million bytes, we wouldnt notice this leak? However, arguing against this idea, it would mean i compiled ~85 Thousand times in an evening... (i dont think so :P ) NaN NaN
Posted on 2001-03-22 10:19:00 by NaN
Seeing as we are ll talking about leaks in general, one common leak i _have_ noticed is the GDI SelectObject leak. Whenever I have ..

invoke SelectObject, hObject
it almost _always_ caused a leak, but i did find a solution. Even I'f i'm never using the origional, or even if windows is never "meant" to be doing the WM_PAINT / WM_"whatever" itself _ALWAYS_ do the reverse SelectObject afterwards ! eg

invoke SelectObject, hDC, hObject
push eax
; put stuff that uses hObject when selected in here
pop eax
invoke SelectObject, hDC, eax
strange, yet seems to kill a lot of leakage :/ Clive
Posted on 2001-03-23 00:35:00 by Entro-P
Clive, That's not strange, that's basic care and handeling of GDI objects. The two basic rules here: 1) If you borrow something, put it back. 2) If you build something, take it apart. Nothing here we weren't taught in kindergarten ;-) When you SelectObject, you're taking the old object out. So when you are done with the DC, you put it back. When a DC is destroyed, it in turn destroys the objects IT owns AT THE TIME OF DESTRUCTION. If you didn't say put the default 1x1 bitmap back, that bitmaps hangs around forever. ------------------------------- "I'm normally not a praying man, but if you're up there, please save me Superman!"
Posted on 2001-03-23 02:42:00 by Ernie
Entro-P: The utility for memory leak detection is NuMega's BoundsChecker. It is designed specifically for such things. You can find BoundsChecker on some cracking sites.
Posted on 2001-03-23 02:56:00 by Iczelion