search

michaeltyson / TPCircularBuffer

A simple, fast circular buffer implementation
http://atastypixel.com/blog/a-simple-fast-circular-buffer-implementation-for-audio-processing/
839 stars 141 forks source link

thread sanitizer warnings on macOS #17

Closed mman closed 6 years ago

mman commented 6 years ago

Hi Michael,

I'm receiving the following thread sanitizer warning (and couple more) when running my app in debug mode on macOS High Sierra and XCode 9.

WARNING: ThreadSanitizer: data race (pid=10371)
  Read of size 8 at 0x00010c0b5058 by thread T27 (mutexes: write M471887713214197208, write M133836300544511056):
  * #0 TPCircularBufferDequeueBufferListFrames <null> (XXXXXX:x86_64+0x100284355)
    #1 myRenderCallback <null> (XXXXXX:x86_64+0x10014b08b)
    #2 AUMultiChannelMixerInputElement::PullMixerInput(unsigned int, unsigned int&, AudioTimeStamp const&, unsigned int, AudioBufferList*) <null> (CoreAudio:x86_64+0x112bb0)

  Previous write of size 8 at 0x00010c0b5058 by main thread:
  * #0 TPCircularBufferPrepareEmptyAudioBufferList <null> (XXXXXX:x86_64+0x10027d92e)
    #1 TPCircularBufferCopyAudioBufferList <null> (XXXXXX:x86_64+0x10027fb84)

  Issue is caused by frames marked with "*".

I'm not sure if I'm using TPCircularBuffer correctly and it seems that the same code is not an issue on the iOS.

The producer will use TPCircularBufferCopyAudioBufferList to fill data into the buffer, the consumer (render callback) uses TPCircularBufferDequeueBufferListFrames to satisfy the render callback requirement...

Am I doing this right? Are these lockless and thread safe on the macOS?

thanks, Martin

michaeltyson commented 6 years ago

Hey Martin - to the best of my knowledge, they are indeed lockless and safe (I've been using them for years in stuff that's seen a huge amount of use). Could be the sanitiser's just been a bit overcautious?

That said, although I'm a CS grad and mostly know what I'm doing, I don't have any skills in stuff like formally proving that this is safe. I just think it is =)

mman commented 6 years ago

Thanks @michaeltyson for confirming this. I have not received any related crashes so far either, I just wanted it here indexed by google if any other people stumble on this via XCode as well.

Since thread sanitizer is not reporting the same thing on the iOS (neither the device nor the simulator) I wonder whether there could be any differences in how the structures are laid out on iOS compiled for x86_64 and arm64 and macOS compiled for x86_64....

Looks like thread sanitizer thinks it can not guarantee atomicity of Read of size 8 and Write of size 8 on macOS, or perhaps that's because the code is compiled for i386 still?

michaeltyson commented 6 years ago

That’s an interesting point - do Mac builds still include a 32 bit slice? Still not sure why that’d be an issue as TPCB uses 32 bit ints, though...

Any way of knowing what line is triggering those warnings? If it’s doing a 64-bit read/write maybe that’s the atomic int...

mman commented 6 years ago

@michaeltyson Please ignore this issue. I discovered a problem in my git repo setup and I think I was probably running against a very old copy of TPCircularBuffer. Just git pull-ed the 1.5 and re-tested the code and the thread sanitizer warnings are gone. Looks like they might have been just fixed ages ago on your side and I was just mistakenly stuck on an old version :)

michaeltyson commented 6 years ago

Ah good!