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.
>> 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.
4 comments
[ 2.6 ms ] story [ 18.4 ms ] threadAlso, 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.
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.