Leaking memory from window's extra bytes?

0
votes

I am making a window C++ class and I am using extra bytes for each window created (using the cbWndExtra of the WNDCLASSEX struct, etc) when registering the window class. Does ::DestroyWindow(..) release the allocated window's extra bytes?

It seems that when I create and destroy many window objects in a loop the "Commit Size" of my app in Task Manager rises.

My C++ class does not allocate any memory, moreover it has no controls/toolbars/menus on it, it does not seem to leak any GDI objects or anything like that, so I suspect it is something with the extra bytes of the window.

Does anyone have any ideas on what can be going wrong?

Is there some API I should call to release the extra bytes?

Is there something else you must do when destroying a window that is using extra bytes?

EDIT: I did try creating just a single window of the specific class that uses the extra bytes and destroying it in a loop and, again, the commit size of my app rises. I also waited for a few hours and the the commit size didn't decrease at all. The extra bytes contain only a pointer to the object that represents the window. This object gets destroyed (it is created statically in the loop). Anyway, it seems that it's not my fault and that it might not even be a bug of Windows (as you say - although I'm not 100% sure) so I'm about to leave it as is...

2
c++winapimemorymemory-leaks
If you don't allocate any memory, and you destroy all your windows, then there is no leak. – David Heffernan
Memory management in Windows is far too sophisticated to reverse-engineer from a simple statistic like Commit size. Use a profiler. Only bother when you can actually get the program to bomb on OOM after running it for a week. Or a minute or two with a unit test. – Hans Passant

2 Answers

5
votes

Yes, it does release the extra bytes. Maybe you're storing pointers to allocated memory in them, and that's what's leaking.

Also, “Commit size” not going down does not prove a memory leak. Allocators don't immediately return freed memory to the OS, they can keep it and reuse later. Try creating a simple CreateWindowEx/DestroyWindow infinite loop to verify.

0
votes

It's your job to release any memory you reference by setting the cbWndExtra field. If you think about it this makes sense since Windows has no knowledge of how you allocated the memory in the first place (eg malloc, new, LocalAlloc etc)

EDIT: Since I've had a downvote maybe I wasn't being clear. If you stick a pointer into the field and it points to something you've allocated in your app then that memory won't be released. The extra bytes will be, but not what they point to.