• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Memory Leak in AudioHardwareGetProperty
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Memory Leak in AudioHardwareGetProperty


  • Subject: Re: Memory Leak in AudioHardwareGetProperty
  • From: "Art Gillespie" <email@hidden>
  • Date: Mon, 24 Jul 2006 12:58:09 -0700

Thanks for the clarification, Jeff.

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?

In any case, thanks again for clarifying.

Best,

Art

On 7/24/06, Jeff Moore <email@hidden > 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 );


--

Jeff Moore
Core Audio
Apple


_______________________________________________
Do not post admin requests to the list. They will be ignored.
 _______________________________________________
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

  • Follow-Ups:
    • Re: Memory Leak in AudioHardwareGetProperty
      • From: Jeff Moore <email@hidden>
References: 
 >Memory Leak in AudioHardwareGetProperty (From: "Art Gillespie" <email@hidden>)
 >Re: Memory Leak in AudioHardwareGetProperty (From: Jeff Moore <email@hidden>)
 >Re: Memory Leak in AudioHardwareGetProperty (From: Hidetomo Katsura <email@hidden>)
 >Re: Memory Leak in AudioHardwareGetProperty (From: Jeff Moore <email@hidden>)

  • Prev by Date: Re: Audio files and loop marker question
  • Next by Date: Re: Memory Leak in AudioHardwareGetProperty
  • Previous by thread: Re: Memory Leak in AudioHardwareGetProperty
  • Next by thread: Re: Memory Leak in AudioHardwareGetProperty
  • Index(es):
    • Date
    • Thread