Re: Memory Leak in AudioHardwareGetProperty
Re: Memory Leak in AudioHardwareGetProperty
- Subject: Re: Memory Leak in AudioHardwareGetProperty
- From: Jeff Moore <email@hidden>
- Date: Mon, 24 Jul 2006 15:16:20 -0700
The only reason I mentioned this was that it has bit me in the behind
over the years. I figured I'd share some of my experience and save
you from similar headaches. My bad.
Obviously you know what you are doing so feel free to ignore me. But
you can't really complain about false positives in your code. This is
inevitable because global operator new/delete are shared by every
single line of C++ code executing in a process whether it is system
code like the HAL or app code. C++ provides many excellent ways to
achieve what you want to do without using the blunderbuss that is
overriding global operators.
BTW, what the HAL is doing is totally above board. The HAL has to
allocate quite a few resources as part of it's initialization. These
resources are used throughout the life cycle of the process, so the
only possible time they can be released is when the process
terminates. To add to the fun, the HAL purposefully avoids doing any
sort of deep clean-up or deallocation at process tear down time too.
The reason why is that the kernel cleans up _all_ the resources used
by a process when that process is reaped. There is no point to
calling operator delete on any particular object as the kernel is
going to get rid of the whole heap containing the object anyway. All
you'd do is succeed in increasing the amount of time the beach ball
spins when you hit quit in your app.
On Jul 24, 2006, at 2:40 PM, Art Gillespie wrote:
On 7/24/06, Jeff Moore <email@hidden> wrote:Sounds to me like
you have a design problem with your memory leak
detection code then. You should definitely _not_ be overriding
operator new/delete on a global level. This not only decreases the
signal to noise ratio of your leak detection,
That's certainly a potential drawback. Then again, the current
system works well (reports zero leaks after a representative run)
on Linux, Windows and OS X -- once I adjusted for CoreAudio's
initialization, of course.
but it also can
introduce bugs in other peoples frameworks as your new allocator
pretty much won't have the same performance/behavior as the normal
allocator.
Interesting. How does one screw up the meaning, behavior or
performance of
void * operator new ( size_t size )
Not to mention, there are plenty of frameworks that have
custom allocators that you are basically overriding.
Class-local overrides take precedence over global new/delete, so
I'm not sure how I could override them.
As such, IMHO,
this is not a stable test platform and you can't really trust the
results from something like that.
Crap... and here I was all exuberant that I had no leaks and it
turns out my memory debugging system sucks. IYHO.
The right thing to do is to override operator new/delete on a class
by class basis (which can be helped by introducing a common base
class). That way you confine your custom allocator to your own code.
Thanks for the design advice, Jeff. Since the name of this list is
'coreaudio-api' and not 'c++-for-dummies' or 'arts-absurd-leak-
detection-methods', I was hoping to get back to my humble
suggestion that the virtual certainty of a false positive memory
leak (regardless of the detection method) be mentioned in the
header (or elsewhere) in the hopes that some hapless developer can
avoid the time-suck of hunting it down (and the subsequent tit-for-
tat on coreaudio-api) Is your answer 'class-local allocator'?
Best,
Art
You won't see the noise from the system (pretty much all frameworks
operate like the HAL where they allocate a bunch of stuff during
initialization that won't be released until the process exits) and
you won't potentially introduce bugs in other frameworks by messing
with their allocator.
On Jul 24, 2006, at 12:58 PM, Art Gillespie wrote:
> For my part, I wasn't using leaks; debug builds using our
> application framework override new(), delete(), new[] and delete[]
> and I was seeing a bunch of new()s without corresponding delete()s
> before process termination. As Katsura suggests, one can spend a
> fair amount of time hunting this down in search of his own
> legitimate leaks... since normal methods can't account for the
> HALs references, perhaps it would be useful to mention this
> behavior in the header?
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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