Re: Memory Leak in AudioHardwareGetProperty
Re: Memory Leak in AudioHardwareGetProperty
- Subject: Re: Memory Leak in AudioHardwareGetProperty
- From: Rick Sustek <email@hidden>
- Date: Mon, 24 Jul 2006 15:12:08 -0700
Yes, this is an unfortunate, but typical reality of memory leak
detection tools.
Without some form of tagging mechanism, how would a tool know that a
reference was intended to be kept for a long period, versus an
unintended leak?
There are many cases of references being held for "long periods".
Some references are held for the entire life of a program. Others are
created when a program launches, but then may be replaced when a user
performs some action. Others come and go periodically.
A "long time" is purely relative. But, from the perspective of a leak
detection tool, anything longer than the sample period is "long". If
the sample period does not "see" the deallocation, it will flag it as
something to be concerned about. The other condition, is when the
tool captures a deallocation during its sample period, for an object
that was allocated *before* the sample period began. This is also
extraneous data.
I've found it very useful to post-process the data produced by leak
tools, to filter out items that are made by modules that are not my
own. You need to have some level of trust in your library providers,
believing that they regularly leak test their code before release,
and keep focus on your own modules. (Of course Apple is doing
this ;-)))))
That said, I have found leaks in vendor's code, for example, a major
provider of CORBA ORB code, where leaks are deadly due to the volume
of invocations.
A good trick to help focus on your own code, is to allocate from
separate or specific regions when the operating environment provides
such a feature. This allows you to filter by region. Another simple
trick is wrap your allocation/deallocation calls in some uniquely
named function. Then, when post-processing the leak datum, you can
throw out all samples that do not have that function name in the call
stack.
Have fun,
-Rick
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden