On Tuesday, August 5, 2003, at 12:05 PM, Scott Becker wrote:

>
> Kevin D. Bond wrote:
>
>> Unfortunately, the Microsoft memory leak detection, in addition to
>> real memory leaks complains about some memory that was allocated,
>> but not freed.
>
>
> Huh??? In my years of programming on windows I've never read in any
> docs that allocated memory will be freed upon exit (even though in
> probably is).

As I said, all memory in an application that is not explicitly freed is
implicitly freed on exit. In the wonderful world of virtual memory,
things have to work this way, once the virtual address space is
destroyed so is all of its contents. Under Windows 3.1 and to some
extent in Windows 95/98/Me, there was a program heap and a system heap
and memory allocated in the system heap if not freed would never be
recovered until a system reboot.

There are lots of cases where libraries depend on this behavior for
allocating things like lookup tables and work buffers, that need to be
created at startup and exist for the duration of the program.

> Therefore if the memory tool is building it's report upon exit, any
> allocated memory, even if it was intended to be allocated for the life
> of the app, which is not freed is considered leak. If the program
> doesn't depend upon the OS cleaning up but instead explicitly frees
> all allocated memory then the report should point only to the ones we
> are trying to find.
>

Granted the best practice is to always free what is generated (with
some exceptions). However, it is not always practical. Commercial
memory leak detection tools differentiate between memory to which no
program resource points and memory which was simply not explicitly
freed. I was just trying to point out the weakness in the Microsoft
tool.

-kevin

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
Received on 2003-08-05