An idea on detecting memory leak -- focus on leaking source location

(Note: This article is a discussion on the new feature added to Denomo V1.0.3, but the concept discussed here is general and not limited to Denomo.)

If my memory serves, several memory leak detection tools I've tested or used, include AQTime, BoundsChecker, the predecessor of Denomo that written by me, are all focusing reporting all memory leak blocks as many as possible.
That's to say, if your program leaks 100 memory blocks, those tools report exactly 100 blocks.
That sounds good because you can get the most detailed information. But please wait for a minute and make a thinking: is so much information really good to you? Or let's think from another view: what do we want to do? Gathering the information? The answer is definitely not. We don't want the leak information, we only want to fix the bugs that cause the memory leaks. Thus much leak information maybe good, but also maybe bad.

Let's take an extreme example. If the program you are developing is a very complex science computing program with very deep recursions and loops, one trivial memory leak bug in the most inner loop may cause millions of leak blocks. Reporting so many leaks will cause very long time, and the worst thing is that you will be lost among the huge amount of leaks. How can you deal with millions of leak report by hand? And that's only a trivial bug, it's not worth wasting the time checking millions of leaks.

Although above example is very extreme, it may happen in the real world (in fact, as far as I know, that's a real story). And even if the report leak count is only several hundreds, it will still cause you rather long time to check all the leaks.

Now let's re-think my previous question, what we want to do? The answer is we want to fix memory leak bugs. So how to find then fix them? The answer is we have to find *where* the leaks occur.

So now we can get a conclusion: for a memory leak detection tool, it will be more helpful to focus on reporting the source location where the leak occurs rather than reporting all of the leaks blocks.

I had fuzzy concept on that conclusion when developing Denomo from version 1.0.0 to 1.0.2, that's why I added "eliminate derived leaks which allocated from a leaked object's constructor" feature in 1.0.0. When I was doing some optimization during developing 1.0.2, I got rather clearer concept on that and eventually implement the "eliminate all leaks allocated from the same calling path" feature in 1.0.3. That feature helps to report different leak location and hide different leak blocks which are leaked from the same location. The result is dramatically. Now Denomo can hide most leaks and only report very few leaks which are worth you focus on. And if you fix the leaks that reported by Denomo, all or most of the hidden leaks will be fixed automatically.
This feature is really cool. It can save you much time and help you to focus on the high priority thing.

Though now Denomo can hide most unimportant leaks, I don't think it's the final success. I will continue thinking about how to distinguish and eliminate unimportant leaks. And if you have any idea, don't hesitate to let me know.