• 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: Jeff Moore <email@hidden>
  • Date: Mon, 24 Jul 2006 13:07:29 -0700

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.

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.

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 (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: Memory Leak in AudioHardwareGetProperty
      • From: Stephen Davis <email@hidden>
    • Re: Memory Leak in AudioHardwareGetProperty
      • From: "Art Gillespie" <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>)
 >Re: Memory Leak in AudioHardwareGetProperty (From: "Art Gillespie" <email@hidden>)

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