HeapAlloc: Automatically freed on exit??

[jj2007]

I remember having read somewhere (MSDN?) that on ExitProcess all memory owned by the process will be released. Now I had a misbehaving app that allocated but forget to deallocate, and just exited. After a while, my computer went into slow motion - after leaving the app, and without crashing it. Now my noob question: How is that possible if Windows cleans up on ExitProcess...? ::)

[dedndave]

hiya Jochen - Z says hi
i am reminded of a story about a guy that went to the doctor...
Patient: "Doctor, it hurts when i bend my elbow this way"
Doctor: "Then, don't bend your elbow that way" ("...that'll be $200, please")

i suppose it is old habit from days of DOS, but i always try to clean up before exit
i even balance the stack - lol - even though i am sure there is probably a leave instruction that soon follows

[Slugsnack]

i don't think the two events are related. even assuming the system failed to free this memory, unless you allocated a HUGE amount ( which people tend not to do with HeapAlloc() ), the memory leak would probably not be noticable

significantly noticeable memory leaks tend to be from things like a leak in a library function or something that is called loads and loads of times

[Astro]

Even if you create a private heap first, it appears the system tracks this anyway.

I tried to deliberately write an app that leaked a cool 1Gb of memory a time, but it would appear I need to try a bit harder.  :cheekygreen:

I too read on MSDN that it frees process heap automatically, but MS still recommend you do this yourself anyway.

There must be other ways of allocating memory that I haven't found yet.

Best regards,
Astro.

[jj2007]

i don't think the two events are related. even assuming the system failed to free this memory, unless you allocated a HUGE amount ( which people tend not to do with HeapAlloc() ), the memory leak would probably not be noticable

significantly noticeable memory leaks tend to be from things like a leak in a library function or something that is called loads and loads of times

Well, the proc inside the misbehaving app was called "StressTest" - it did allocate HUGE amounts; and I am pretty sure the slowing down was caused by not releasing it before ExitProcess. The same app works fine now, and does no longer cause problems. Mysteries of Windows...!

@Dave: Greetings to Zara, and all the best to you. I am currently on a slow analog modem, and keep my net activity to the absolute minimum...

[hutch--]

I have found with practice that memory deallocation is laggy which means the OS gets around to it eventually but not necessarily straight after you have freed the memory. Depending on the strategy of allocation (Heap, Global, Virtual etc ...), some handle this better than others. I still prefer the old GlobalAlloc() using the FIXED flag as it is unproblematic in allocating and freeing large blocks of memory, (1 gig +).

[Slugsnack]

the thing is, unless you run out of physical memory AND the space on the HDD ( swap file ) you are unlikely to see a huge difference in performance. since the pages your process used are no longer needed as virtual memory they will be swapped out of the physical memory to prevent TLB misses and will reside instead in the swap file. so in theory, the extra memory, assuming it has not been released should be left unused. it should not even be touched because the dirty bit should remain unchanged

of course this is all theoretical.. and what is SUPPOSED to happen

[jj2007]

Update: My "stresstest" causes roughly half a million page faults ;-)
On one occasion, it exited with a HeapAlloc failure (at 500,000 page faults) but managed to free the allocated heap without errors. Afterwards, Windows remained slow, though.
With another setting, the app crashes, at the same amount of page faults, and afterwards Windows becomes so slow that I have to reboot - even the desktop needs several seconds to redraw.
By the way: the second in Task Manager's list, sorted by page faults, is AvGuard.exe, with 200, 000 page faults. Might be a nice strategy to give lots of food to this app until it crashes...
Conclusion: Windows does not release the process heap.

[dedndave]

what version of windowz Jochen ?
it could be an OS or even a SP-level thing

[jj2007]

what version of windowz Jochen ?
it could be an OS or even a SP-level thing

XP SP2

Raymond Chen on ExitProcess:

Note that I just refer to it as the way processes exit on Windows XP rather than saying that it is how process exit is designed. As one of my colleagues put it, "Using the word design to describe this is like using the term swimming pool to refer to a puddle in your garden."

...

But wait, it gets worse. That critical section might have been the one that protects the process heap! If one of the threads that got terminated happened to be in the middle of a heap function like HeapAllocate or LocalFree, then the process heap may very well be inconsistent. If your DLL_PROCESS_DETACH tries to allocate or free memory, it may crash due to a corrupted heap.

Moral of the story: If you're getting a DLL_PROCESS_DETACH due to process termination,† don't try anything clever. Just return without doing anything and let the normal process clean-up happen. The kernel will close all your open handles to kernel objects. Any memory you allocated will be freed automatically when the process's address space is torn down. Just let the process die a quiet death.