• 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: I thought audio processing threads weren't supposed to call malloc
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I thought audio processing threads weren't supposed to call malloc

  • Subject: Re: I thought audio processing threads weren't supposed to call malloc
  • From: Kevin Dixon <email@hidden>
  • Date: Mon, 22 Dec 2014 14:20:45 -0800
Do as I say not as I do. They are using an STL container which is using the new operator, which is implemented with malloc. They probably couldn't be bothered to write a custom allocator that used preallocated memory or something.

On Mon, Dec 22, 2014 at 2:09 PM, Taylor Holliday <email@hidden> wrote:
Yet I see CoreAudio doing it:

* thread #10: tid = 0x4b78b, 0x00007fff95ea436b libsystem_malloc.dylib`malloc, name = 'DSP thread', stop reason = breakpoint 6.11

  * frame #0: 0x00007fff95ea436b libsystem_malloc.dylib`malloc

    frame #1: 0x00007fff936f923e libc++abi.dylib`operator new(unsigned long) + 30

    frame #2: 0x00007fff901dbf0c CoreAudio`void std::__1::vector<CAPropertyAddress, std::__1::allocator<CAPropertyAddress> >::__push_back_slow_path<CAPropertyAddress>(CAPropertyAddress&&) + 180

    frame #3: 0x00007fff901d05ea CoreAudio`CAPropertyAddressList::AppendItem(AudioObjectPropertyAddress const&) + 74

    frame #4: 0x00007fff901aefb3 CoreAudio`HALObject::PropertiesChanged(unsigned int, AudioObjectPropertyAddress const*) + 441

    frame #5: 0x00007fff901aecde CoreAudio`HALDevice::PropertiesChanged(unsigned int, AudioObjectPropertyAddress const*) + 438

    frame #6: 0x00007fff901bb9ee CoreAudio`HALSystem::AudioObjectPropertiesChanged(AudioHardwarePlugInInterface**, unsigned int, unsigned int, AudioObjectPropertyAddress const*) + 158

    frame #7: 0x00007fff901c4009 CoreAudio`HALC_ProxyIOContext::IOWorkLoop() + 1121

    frame #8: 0x00007fff901c3b0e CoreAudio`HALC_ProxyIOContext::IOThreadEntry(void*) + 88

    frame #9: 0x00007fff901c39eb CoreAudio`HALB_IOThread::Entry(void*) + 157

    frame #10: 0x00007fff8dcc02fc libsystem_pthread.dylib`_pthread_body + 131

    frame #11: 0x00007fff8dcc0279 libsystem_pthread.dylib`_pthread_start + 176

 

    frame #12: 0x00007fff8dcbe4b1 libsystem_pthread.dylib`thread_start + 13


Am I misreading this?

 _______________________________________________
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

 _______________________________________________
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
References: 
 >I thought audio processing threads weren't supposed to call malloc (From: Taylor Holliday <email@hidden>)

  • Prev by Date: I thought audio processing threads weren't supposed to call malloc
  • Next by Date: RE: I thought audio processing threads weren't supposed to call malloc
  • Previous by thread: I thought audio processing threads weren't supposed to call malloc
  • Next by thread: RE: I thought audio processing threads weren't supposed to call malloc
  • Index(es):
    • Date
    • Thread