Re: PrintScreen & IVideoWindow

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

"Alessandro Angeli [MVP::DS/MF]" <nobody@xxxxxxxxxxxxxxxxxx> wrote in
message news:udbyjnZZGHA.3448@xxxxxxxxxxxxxxxxxxxxxxx
offtopic. how to debug such leaks ?

The guys here suggest to use smart COM pointers to avoid reference leaks
to begin with.

As we have seen from previous posts, the "smart" COM pointers don't
eliminate leaks, nor guarantee avoidance of other problems. They are
helpful, especially for programmers who don't have practice being very
detailed about their references. But they aren't a panacea.

To the original poster, I had the pleasure (no, really :) ) of implementing
debug code to help track and debug memory leaks in a couple of projects I
used to work on. We already had leak-detection code, but it was a royal
pain trying to figure where the memory had been allocated (even when you
could tell what the memory held), never mind who should have freed it.

I added a header to the custom-allocated memory blocks in which I stored the
last six return addresses from the stack. This was a while ago, and I had
to write the code to walk the stack by hand; we deciphered the addresses
simply by having the debugger disassemble the code at the address (it would
display the symbol corresponding to the address in the dump...I was too lazy
to add code to grab the symbol table and do the look-up automatically :) )).
Of course, these days you have tools like DbgHelp to do the heavy-lifting
for you. For all I know, it'll walk the stack for you too (don't
know...haven't looked at it recently).

Even if you do everything by hand, it's not that hard to implement. And the
ease with which debugging memory leaks becomes is invaluable. I don't know
why this sort of functionality isn't built into the debug libraries already.
The need has existed ever since the first programmer allocated a block of
memory, and with all the strides development environments have made over the
years, it amazes me that it's always still a mystery where a leaked block of
memory came from.

I suppose these days it might take more than six stack frames to reliably
know why a block was allocated and who should have freed it. But there's a
lot more RAM to play with too. Whatever, the basic idea is sound and I can
speak from personal experience to say that it really helps.

Pete


.

Relevant Pages

  • Re: ANN: FastMM 4.40 released (replacement memory manager for Delphi IDE and applications, free and
    ... > A fast replacement memory manager for Borland Delphi Win32 ... FastMM is designed for an average of 5% and maximum ... > manager) - Optionally reports memory leaks on program shutdown. ... > negating the need for stack frames. ...
    (borland.public.delphi.thirdpartytools.general)
  • ANN: FastMM 4.40 released (replacement memory manager for Delphi IDE and applications, free and open
    ... A fast replacement memory manager for Borland Delphi Win32 applications ... - Optionally reports memory leaks on program shutdown. ... the need for stack frames. ... - Before performing a "raw" stack trace, FastMM now checks whether ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: Memory leak without handle leak?
    ... > I'm trying to debug a memory leak problem I'm having on windows 2003. ... > the stack trace for the leaks doesn't originate from my code. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: If Macs have no spyware....
    ... >had made a complete code review of its operating system and removed all ... and writing new data into those memory locations would ... >but when the data exists on the stack, it can cause very large problems. ... >location that needs to be written in place of the correct execution ...
    (comp.sys.mac.advocacy)
  • Re: If Macs have no spyware....
    ... First you yammer about being a Mac advocate, then bad mouth me for dumping XP in favor of a Mac. ... Supposedly Microsoft had made a complete code review of its operating system and removed all the buffers which could overflow. ... the fundamental problem is that the basic architecture of Windows has two fatal flaws in its memory management and while these remain in the software the ad hoc patches will never be enough to make Windows a secure operating system. ... These problems are bad enough when dealing with data in the one routine but when the data exists on the stack, it can cause very large problems. ...
    (comp.sys.mac.advocacy)