

Caches are nice, but they confuse memory leak detection tools - edw519
http://blogs.msdn.com/oldnewthing/archive/2009/11/27/9929238.aspx

======
ajg1977
This seems like a very general and somewhat misleading statement that's based
on a naively instrumented/integrated analysis tool.

~~~
jmostert2
Judging a blog post by its title alone is hardly fair. Raymond clearly
explains what it's about in the post itself. No pretenses about full
generality are being made. "Some caches confuse some memory leak detection
tools" may be more accurate, but it's hardly catchy.

Also, analysis is only as good as what you know to analyse. Calling a memory
analysis "naive" because it bases itself only on the system
allocation/deallocation routines (which are, after all, the logical starting
point for any such analysis) is just silly. Sure, the analyzer could have been
extended to know about BSTR caching, but there's obviously no limit to the
amount of cleverness you need to build in to properly analyze everything this
way. Any sufficiently advanced cache is indistinguishable from a memory leak,
that's sort of the point.

~~~
ajg1977
>> Calling a memory analysis "naive" because it bases itself only on the
system allocation/deallocation routines is just silly <<

No, it's being accurate. Reporting leaks based on mismatched alloc/dealloc
system calls is a fair starting point, but is still a naive technique.

For example detecting resource leaks can either be done by instrumenting the
program itself, or tracking calls to the underlying OS routines. If the
tracking was based on the program then everything would be peachy since the
create/free calls match. But it's not, it uses system calls and seemingly
discounts the potential for resources not to live beyond their use in the
program. And that's naive.

>> Any sufficiently advanced cache is indistinguishable from a memory leak,
that's sort of the point. <<

I suppose that depends on your definition of a leak. Mine is "no longer
referenced", which a cached item clearly is.

------
rphlx
They don't confuse valgrind. If a pointer to the object exists in valid
address space at shutdown, it's not technically a leak.

