Caches are nice, but they confuse memory leak detection tools
1–5 of 5 posts
Re: Caches are nice, but they confuse memory leak detection tools
#2This seems like a very general and somewhat misleading statement that's based on a naively instrumented/integrated analysis tool.
Re: Caches are nice, but they confuse memory leak detection tools
#3This seems like a very general and somewhat misleading statement that's based on a naively instrumented/integrated analysis tool.
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.
Re: Caches are nice, but they confuse memory leak detection tools
#4This seems like a very general and somewhat misleading statement that's based on a naively instrumented/integrated analysis tool.
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/deal…
>> 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.
Re: Caches are nice, but they confuse memory leak detection tools
#5They don't confuse valgrind. If a pointer to the object exists in valid address space at shutdown, it's not technically a leak.