Re: Memory Leak in AudioHardwareGetProperty
Re: Memory Leak in AudioHardwareGetProperty
- Subject: Re: Memory Leak in AudioHardwareGetProperty
- From: "Art Gillespie" <email@hidden>
- Date: Mon, 24 Jul 2006 14:40:51 -0700
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 (
This email sent to email@hidden
_______________________________________________
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