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 17:11:23 -0700
On Jul 24, 2006, at 4:34 PM, Art Gillespie wrote:
On 7/24/06, Jeff Moore <email@hidden> wrote:
Obviously you know what you are doing so feel free to ignore me.
Did you really just give me permission to ignore you?
Absolutely. It is always an option. Sometimes the best one.
But
you can't really complain about false positives in your code.
I didn't. I wouldn't. What I did was:
a) asked if it was a memory leak or initialization
b) thanked you for your response and made the suggestion that
documentation might save someone a bit of time down the road.
I stand corrected.
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.
I'd be less inclined to take you up on your offer of ignoring you
if you actually gave a concrete, techncal example of why
'overriding global operators is bad mmmm'kay?' In the absence of
this--or any relevant hits on a search for 'c++ blunderbuss global
operators'-- I'm more inclined to take things at face value.
The last time I saw with this was in an app that over-rode operator
new to do leak detection. It did not provide the same implementation
for address alignment that the standard operator new did. This caused
the app to crash randomly because some altivec code made assumptions
about the address alignment and was writing off one of the ends of a
buffer and smashing memory. This was very difficult to track down.
All I'm saying is that pulling the rug out from under code whose
allocation/deallocation requirements you don't know anything about is
fraught with peril that is easy to avoid. Both C++ and gcc provide
ways to narrow the scope of your override so that it doesn't cause
any collateral damage.
BTW, what the HAL is doing is totally above board. <snipped
explanation>
We agree there... in my original message I posited that it might
very well be setup code based on the once-only behavior I was
seeing. I'm not some dogmatic fringe extremist C++ cleric who
thinks a singleton is a memory leak. I was only seeking
confirmation one way or the other.
Thanks once again for the clarification. As for my suggestion for
a clarifying note in the docs, I suspect that this thread will
suffice.
As long as it caries the caveat that all of this is subject to change
at any time. It is an implementation detail. Memory usage patterns
are ephemeral due to the complex interactions between the different
parts of the system.
Plus, things evolve. For example, suppose some system update changes
a system call's implementation. This change forces the HAL to get
initialized before you start your leak profiling. This would cause
all the HAL's initialization "leaks" to vanish from your profiling
even though nothing has substantially changed in your app or the HAL.
Why chase ghosts when you don't have to?
--
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