Re: Memory Leak in AudioHardwareGetProperty
Re: Memory Leak in AudioHardwareGetProperty
- Subject: Re: Memory Leak in AudioHardwareGetProperty
- From: Hidetomo Katsura <email@hidden>
- Date: Mon, 24 Jul 2006 12:47:11 -0700
okay. thanks for the explanation. it is indeed very unfortunate.
i guess i'm talking about all other leaks that don't keep the
references and are real leaks.
it doesn't matter the reasons behind it. it's just very annoying.
On Jul 24, 2006, at 12:25 PM, Jeff Moore wrote:
In the case of the HAL, none of the memory is leaked. The HAL
maintains references to all those bits of memory. Unfotunately,
those references are in places where the leaks tool doesn't/can't
actually look. This is a well-known problem with the tool as it
tends to be conservative and produce lots of false positives rather
than potentially missing something.
On Jul 24, 2006, at 12:09 PM, Hidetomo Katsura wrote:
can you make it leaks command friendly (just keep the pointer
somewhere) so that leaks doesn't report it as a leak and
developers can focus on real leaks, please?
it's not just AudioHardwareGetProperty by the way, there are so
many OS level leaks (some real, some not) that show up in the
leaks report and make it difficult to find my own leaks.
On Jul 24, 2006, at 11:54 AM, Jeff Moore wrote:
That's not a leak, that's the HAL initializing itself. That
memory will get released when the process is reaped.
On Jul 21, 2006, at 11:07 AM, Art Gillespie wrote:
The code below triggers a bunch of calls to new(), resulting in
2084 bytes on the heap that never get deleted.
---
AudioDeviceID ret;
UInt32 theSize = sizeof(AudioDeviceID);
AudioHardwareGetProperty
( kAudioHardwarePropertyDefaultOutputDevice,
&theSize,
&ret );
_______________________________________________
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