AddressSanitizer: heap-buffer-overflow in EMPTY plugin

Audio Plugins
1

I have some issues with my plugin, related to writing a .wav file from a AudioBuffer. Maybe I’ll follow up on this as well, but when I was about to diagnose the issue, it would really help to do real debugging, not only Log writing.

So I started my plugin as Standalone with the Debugger attached. It started to show address violations in parts of the code I didn’t expect. So I enabled AddressSanitizer to maybe get more that just a plain address.

After running with AddressSanitizer I didn’t even get to the code, bc it kicked in before. As I could not imagine anything, I tried to create a empty plugin from Projucer:

  • Created new Projucer project
  • Enabled VST/AU/AAX/Standalone and Xcode
  • Generate the XCode Project
  • Didn’t set any settings or edited any code
  • Open XCode
  • Enabled AddressSanitizer
  • Start project

It kicks in at the same code location than in my actual plugin:

(lldb) thread backtrace
* thread #7, name = 'com.apple.audio.IOThread.client', stop reason = Heap buffer overflow
    frame #0: 0x000000010a0c32cc libclang_rt.asan_osx_dynamic.dylib`__asan::AsanDie()
    frame #1: 0x000000010a0dd1d0 libclang_rt.asan_osx_dynamic.dylib`__sanitizer::Die() + 192
    frame #2: 0x000000010a0c116c libclang_rt.asan_osx_dynamic.dylib`__asan::ScopedInErrorReport::~ScopedInErrorReport() + 1172
    frame #3: 0x000000010a0c03c8 libclang_rt.asan_osx_dynamic.dylib`__asan::ReportGenericError(unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool) + 1968
    frame #4: 0x000000010a0c1e98 libclang_rt.asan_osx_dynamic.dylib`__asan_report_store4 + 64
  * frame #5: 0x00000001051124d4 TestPlugin`juce::CoreAudioClasses::CoreAudioInternal::audioCallback(this=0x00006130000519c0, inputTimestamp=0x000000010cfd80a0, outputTimestamp=0x000000010cfd80e0, inInputData=0x000060300006a060, outOutputData=0x000060200001e030) at juce_CoreAudio_mac.cpp:795:33
    frame #6: 0x0000000105111958 TestPlugin`juce::CoreAudioClasses::CoreAudioInternal::audioIOProc((null)=112, inNow=0x000000010cfd8060, inInputData=0x000060300006a060, inInputTime=0x000000010cfd80a0, outOutputData=0x000060200001e030, inOutputTime=0x000000010cfd80e0, device=0x00006130000519c0) at juce_CoreAudio_mac.cpp:1146:51
    frame #7: 0x00000001901f4830 CoreAudio`HALC_ProxyIOContext::IOWorkLoop() + 11636
    frame #8: 0x00000001901f13a8 CoreAudio`invocation function for block in HALC_ProxyIOContext::HALC_ProxyIOContext(unsigned int, unsigned int) + 172
    frame #9: 0x000000019039b37c CoreAudio`HALC_IOThread::Entry(void*) + 88
    frame #10: 0x000000010a0b64a8 libclang_rt.asan_osx_dynamic.dylib`asan_thread_start(void*) + 80
    frame #11: 0x0000000109b6508c libsystem_pthread.dylib`_pthread_start + 136

My System Information:

  • Mac Book Pro 2021 / Apple M1 Pro / macOS 15.5 (24F74)
  • Logic Pro 11.1.2
  • Xcode 16.3
  • JUCE Version 8.0.7

So my questions are:

  • Is AddressSanitizer supposed to work with JUCE projects?
  • Is that maybe a problem on my system / drivers?
  • Anyone any hints on how to fix that?
2

Yes, I just ran up the DemoRunner with it enabled, with no issues.

Maybe? Are you using a specific audio device? I haven’t tried macOS 15.5 yet, I’m on an older OS version.

Based on the report you’ve shared, assuming you’re using the latest version of JUCE it looks like the issue is here

Looking around a bit more this part of the code looks suspicious…

The bufferSize is potentially updated but the temp buffers are not reallocated. Hard to say without being able to reproduce the issue though.

3

Thank you very much for your comment. This is the exact location where it hits. I just tried to repo again, and something interesting happened:

  • It did NOT hit on the first try
  • After guessing what is different, I powered on my bluetooth headset, and it hit!
  • So it must be related to having multiple devices

Is this a known bug?
Is there a way that I can help diagnose that?