|
From: John R. <jr...@bi...> - 2013-01-07 00:00:14
|
On 01/06/2013 01:24 PM, David Bar wrote:
> That's true for memcheck if interested in memory corruption issues.
DO NOT "TOP POST" IN A TECHNICAL DISCUSSION.
In a technical discussion the responses must be in chronological order
from top to bottom so that the flow of ideas is clear without requiring
back-and-forth scanning. "Top posting" (putting the reply above antecedent)
may be OK for some management discussions within a small group who know
each other personally and are having a quick conversation. In a technical
discussion among possibly many strangers whose language fluency may vary
a lot, and which may span a long time, including searches weeks and months
later, then top posting is a severe impediment.
>
> What about massif? It seems that if we only want memory measurements, wouldn't it be enough to just handle malloc/free/etc.?
If memory leaks matter then it is not obvious that just handling
"malloc/free/etc" suffices. If all you want is
{max,min,integral}(malloc - free)
and massif doesn't perform as you like, then talk directly to massif.
> What if I want to run memcheck just to find memory leaks? Doesn't seem to me that I need actual instrumentation here of all code, no?
Show me the code, or at least explain in detail why this should be true.
I don't believe the claim. In particular, I have programs which
use stem+leaf storage for collections of pointers, and these programs
require _more_ than 100% "observation" just to find memory leaks.
> Even for the complete memcheck functionality, some use cases may live well enough with just instrumenting a part of the program.
Extremely unlikely. Sabotaging only log(n) of the memory references can
totally invalidate nearly every program ever written.
>
> Say I have a huge program, which contain tons of DLLs, most of them not under my responsibility and/or I can't fix the bugs in them. If I just want to memcheck my DLL, and am willing to live with the assumption that memory my DLL allocates is only read/written by my DLL, it seems reasonable to only
> translate and handle my DLL, no?
If you are willing to assume that some DLL is an island unto itself,
then why not test it that way? Also, unless the DLL has been through
an actual theorem prover or an extensive battery of tests then I
don't believe the claim "my DLL is an island."
--
|