Re: Memory Leak in AudioHardwareGetProperty
Re: Memory Leak in AudioHardwareGetProperty
- Subject: Re: Memory Leak in AudioHardwareGetProperty
- From: Stephen Davis <email@hidden>
- Date: Mon, 24 Jul 2006 15:07:31 -0700
On Jul 24, 2006, at 1:07 PM, Jeff Moore 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, 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. Not to mention, there are plenty of frameworks that have
custom allocators that you are basically overriding. As such, IMHO,
this is not a stable test platform and you can't really trust the
results from something like that.
Yes, overriding the frameworks' version of new/delete is not a good
idea.
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. 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.
If you are building with Xcode/gcc 4.0.x, you can override global new
such that it is only visible to your own app and therefore doesn't
override the new/delete used by the system frameworks. To do so, you
define your version of new and friends like so:
__private_extern__ inline __attribute__((always_inline)) void *
operator new( size_t size ) throw (std::bad_alloc)
{
...
}
I don't know why all of those attributes are necessary but they are.
For some reason, this does *not* work for delete() b/c doing so hides
it from everyone, including your own app's code! So, you have to
override the global delete operator for everyone as a partial
solution. Not the best thing in the world since all deletes go
through that version but you won't get false leaks from the frameworks.
hth,
stephen
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?
_______________________________________________
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