# FR: Option for assert on audio thread allocation or syscall

**URL:** <https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151>\
**Category:** Feature Requests\
**Created:** [October 3, 2023, 10:18pm UTC](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151 "2023-10-03T22:18:26Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![kisielk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kisielk/32/1492_2.png) [@kisielk](https://forum.juce.com/u/kisielk)\
**Post date:** [October 3, 2023, 10:18pm UTC](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151/1 "2023-10-03T22:18:26Z")

</div>

We were discussing this on the Audio Programmer Discord today and concluded it would be great if there was an option that could be set via say CMake that was called something like `JUCE_ASSERT_ON_AUDIO_THREAD_ALLOCATION` which would trigger an assert if any function was called from the audio thread that ultimately resulted in a call to `malloc` or `free`. This could probably be implemented in a platform-specific way using malloc hooks. I’m familiar with the [mechanism on Linux](https://www.gnu.org/software/libc/manual/html_node/Hooks-for-Malloc.html) implemented by GCC, and surely something similar must be possible on macOS and Windows as well. This would be a huge help in finding performance-killing code that makes its way into the audio thread. It’s not always easy to identify because it could be hidden deep in some library code _cough JUCE MIDI SysEx cough_.

Perhaps as a stretch goal this could be extended to other syscalls like `open` etc.

---

<div class="post-metadata">

**Author:** ![eggnog](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eggnog/32/12211_2.png) [@eggnog](https://forum.juce.com/u/eggnog)\
**Post date:** [October 3, 2023, 10:20pm UTC](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151/2 "2023-10-03T22:20:20Z")

</div>

I second that. Much needed feature !

---

<div class="post-metadata">

**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\
**Post date:** [October 3, 2023, 10:21pm UTC](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151/3 "2023-10-03T22:21:36Z")

</div>

Would love this as well, especially for bugs like this:

> [@Sysex message allocated on read](https://forum.juce.com/t/sysex-message-allocated-on-read/52966/):
>
> Since the modernization of Midi in JUCE, we iterate over MIDI events like this: juce::MidiBuffer buffer; for (auto m: buffer) { doSomething(m.getMessage()); } With regular midi messages, like notes or MIDI CC, copying the message is fine, as it’s a small stack object. However, with larger Sysex messages, that copy will allocate and call malloc internally inside MidiMessage. Because getMessage() only allows to read the message by copy, I’m not sure there’s a way to get around that? I’d …

It seems like Microsoft has a cross platform solution to create a custom malloc:

> **[GitHub - microsoft/mimalloc: mimalloc is a compact general purpose allocator...](https://github.com/microsoft/mimalloc)**
>
> mimalloc is a compact general purpose allocator with excellent performance. - GitHub - microsoft/mimalloc: mimalloc is a compact general purpose allocator with excellent performance.

---

<div class="post-metadata">

**Author:** ![evanberard](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/evanberard/32/14069_2.png) [@evanberard](https://forum.juce.com/u/evanberard)\
**Post date:** [October 5, 2023, 11:12am UTC](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151/4 "2023-10-05T11:12:41Z")

</div>

I second this! Noticed I accidentally did an allocation when value tree redirected was called. Would have been an easy one to miss

---

<div class="post-metadata">

**Author:** ![oli1](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/oli1/32/15664_2.png) [@oli1](https://forum.juce.com/u/oli1)\
**Post date:** [October 5, 2023, 11:34am UTC](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151/5 "2023-10-05T11:34:48Z")

</div>

I have an allocation hook for Windows, it patches VirtualAlloc in the binary IAT and I use a thread\_local flag to enable asserting on allocation.

I think I can override malloc via the runtime linker on macOS to do the same thing.

I can tidy it up if anyone wants to have a look. Not endorsed by JUCE, obviously.

---

<div class="post-metadata">

**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\
**Post date:** [October 5, 2023, 12:01pm UTC](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151/6 "2023-10-05T12:01:16Z")

</div>

I added an initial version of my allocation checker for Mac (and probably Linux). Hoping to add Windows Support in the next couple of days.

This will hook into malloc/free/calloc/realloc/new and delete in a scoped matter.

> **[GitHub - eyalamirmusic/ScopedMemoryAllocations: Check for memory allocations...](https://github.com/eyalamirmusic/ScopedMemoryAllocations)**
>
> Check for memory allocations in a specific thread, to validate your code for real-time purposes - GitHub - eyalamirmusic/ScopedMemoryAllocations: Check for memory allocations in a specific thread, ...

The usage in CMake is something like that:

```auto
add_subdirectory(ScopedMemoryAllocations)
target_link_libraries(MyPlugin PRIVATE AllocationsChecker)

```

Then in code:

```cpp
#include <ScopedMemoryAllocations/Allocations.h>

void processBlock()
{
    EA::Allocations::ScopedSetter setter;
    //your code
}

```

---

<div class="post-metadata">

**Author:** ![oli1](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/oli1/32/15664_2.png) [@oli1](https://forum.juce.com/u/oli1)\
**Post date:** [October 5, 2023, 12:12pm UTC](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151/7 "2023-10-05T12:12:49Z")

</div>

̶A̶n̶n̶o̶y̶i̶n̶g̶l̶y̶,̶ ̶J̶U̶C̶E̶ ̶s̶t̶i̶l̶l̶ ̶u̶s̶e̶s̶ ̶m̶a̶l̶l̶o̶c̶/̶r̶e̶a̶l̶l̶o̶c̶/̶f̶r̶e̶e̶ ̶i̶n̶ ̶s̶o̶m̶e̶ ̶p̶l̶a̶c̶e̶s̶,̶ ̶w̶h̶i̶c̶h̶ ̶t̶h̶i̶s̶ ̶w̶o̶n̶’̶t̶ ̶c̶a̶t̶c̶h̶.̶

Sorry! So it does, this will do it 👍

---

<div class="post-metadata">

**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\
**Post date:** [October 5, 2023, 12:30pm UTC](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151/8 "2023-10-05T12:30:52Z")

</div>

> [@oli1](#):
>
> Annoyingly, JUCE still uses malloc/realloc/free in some places, which this won’t catch.

Was this a reply to me? My library does catch malloc/calloc and free. Do you have a specific example in JUCE I can experiment with?

---

<div class="post-metadata">

**Author:** ![PluginPenguin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/pluginpenguin/32/10203_2.png) [@PluginPenguin](https://forum.juce.com/u/PluginPenguin)\
**Post date:** [October 5, 2023, 1:39pm UTC](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151/9 "2023-10-05T13:39:40Z")

</div>

We had an allocation detection implementation that worked via malloc hooks integrated in our in-house wrapper for quite some time. While that seemed like a great tool to spot hidden allocations at first the detector turned out to be a source of problems itself.

The main problem is that the malloc hooks are obviously set up for the entire host process, so we need to store the thread ID of the thread currently calling the `processBlock` callback and then in the malloc hook check if the thread id of the thread calling malloc equals this stored id if any is stored. This becomes a bit more complex if you have multiple instances of your plugin in a test project and use them in a host that uses multithreaded rendering – which is pretty standard behaviour nowadays. Now we don’t only have to keep a single ID but a list of ids of audio threads that might possibly be active at the same time. This should also not be too hard. Now if you develop multiple plug-ins, which all want to access this malloc hook, and you load them in the same process you end up with multiple chained malloc hooks which lead to some difficult to track down crashes – I don’t remember the details anymore, but in the end it lead us to put all that functionality into a shared library all our plugins linked against in order to be sure that there is only one malloc hook in the process. However, then there is Logic, which started to inject its own malloc implementation starting at some version, which again caused strange bugs.

I won’t say that there are no solutions to all this, but in the end we realised that all the overhead the integration of this safety feature caused and the bugs that were introduced didn’t outweigh the benefit.

We also noticed that after approximately 2 years with this feature integrated the team had learned so much about sources of possible hidden allocations that we didn’t introduce any of them anymore in new code anyway.

So my conclusion after this journey is: We gained some interesting insight, but I wouldn’t recommend integrating a feature like this on a framework level.

---

<div class="post-metadata">

**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\
**Post date:** [October 5, 2023, 1:54pm UTC](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151/10 "2023-10-05T13:54:31Z")

</div>

> [@PluginPenguin](#):
>
> Now if you develop multiple plug-ins, which all want to access this malloc hook, and you load them in the same process you end up with multiple chained malloc hooks which lead to some difficult to track down crashes

Check out my implementation (linked above), it’s addressing that exact issue by using a scoped setting that is set not only per thread but also per specific callback (with the thread id). Setting up multiple of those either in different threads or different callbacks on the same thread should not be problematic.

---

<div class="post-metadata">

**Author:** ![kisielk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kisielk/32/1492_2.png) [@kisielk](https://forum.juce.com/u/kisielk)\
**Post date:** [October 5, 2023, 3:36pm UTC](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151/11 "2023-10-05T15:36:18Z")

</div>

I don’t think you’d have the allocation checker permanently enabled in a plugin (although you could) but use it more as a development tool and during debug builds. At least that’s what I would do. In that case all the nuances of the host threading implementation etc. wouldn’t matter so much as you’d test it with a simple setup just to make sure no allocations happen. I see it more like something you’d use like ASan, which I try to integrate into all projects when possible. ASan _rarely_ catches anything in my projects, but I still like to use it because things can always sneak through.

---

<div class="post-metadata">

**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\
**Post date:** [October 5, 2023, 4:52pm UTC](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151/12 "2023-10-05T16:52:36Z")

</div>

Yes, this is exactly what I had in mind. I don’t see it as production code, just something that (like ASAN) you run in a debugging environment, or CI. Ideally, this would help flag bugs like the JUCE Sysex bugs, allocations that could happen as a part of `callAsync` from the audio thread, etc.

---

<div class="post-metadata">

**Author:** ![kunitoki](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kunitoki/32/15_2.png) [@kunitoki](https://forum.juce.com/u/kunitoki)\
**Post date:** [October 10, 2023, 6:56am UTC](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151/13 "2023-10-10T06:56:32Z")

</div>

Why you lock and do linear searches in an array every audio block instead of storing a `static thread_local bool this_thread_can_alloc = true` that is set to false at the beginning of the audio block ?

---

<div class="post-metadata">

**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\
**Post date:** [October 10, 2023, 7:28am UTC](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151/14 "2023-10-10T07:28:35Z")

</div>

I just didn’t think of this solution but it certainly sounds like a better idea, I’ll try it!

It is important to note that this is a purely debugging tool and NOT meant to be used in production code, similar to thread/address sanitizer (which also ruin performance while you’re using them), or JUCE\_ENABLE\_REPAINT\_DEBUGGING.

So, the performance overhead of the system shouldn’t have any impact on your “real” code (even if it is not very efficient).

---

<div class="post-metadata">

**Author:** ![kunitoki](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kunitoki/32/15_2.png) [@kunitoki](https://forum.juce.com/u/kunitoki)\
**Post date:** [October 10, 2023, 3:53pm UTC](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151/15 "2023-10-10T15:53:03Z")

</div>

I know, but it doesn’t mean we need to be slower just because it’s a debugging tool. Code will be simpler to maintain and still reasonably efficient (depending on the standard librady thread local implementation).

Also you are not replacing operators new with nothrow\_t and alignment, which will allocate silently.

---

<div class="post-metadata">

**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\
**Post date:** [October 10, 2023, 5:15pm UTC](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151/16 "2023-10-10T17:15:30Z")

</div>

My initial reason to storing an array there is to be able to inspect that array with a breakpoint in case you have multiple threads which is more difficult to do with the local static. I still like the idea of adding the thread local one, but I will first need to test if it actually works correctly, which is more important than performance in this case.

Can you explain your suggestion about operator new? I’m not sure I understand.

---

<div class="post-metadata">

**Author:** ![kunitoki](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kunitoki/32/15_2.png) [@kunitoki](https://forum.juce.com/u/kunitoki)\
**Post date:** [October 10, 2023, 6:09pm UTC](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151/17 "2023-10-10T18:09:25Z")

</div>

Well i honestly don’t use `assert` anymore (at least not directly), i have my own `expect` function which is able to break into the debugger without crashing the app, so i could continue from there the debugging session instead of aborting. Once i’m in the debugger with the expectation failing, i should be already positioned in the failing thread, no need to inspect a vector of thread::id which are not easily mappable to thread names (at least from my debugging experience with these things).

See the c++17 overloads you are not overriding in [[here]](https://en.cppreference.com/w/cpp/memory/new/operator_new). I make use of those via `std::pmr` types for overly aligned containers to use for simd, so these overloads taking the alignment argument are called instead of the plain ones without it (via polymorphic\_allocator / memory\_resource).

---

<div class="post-metadata">

**Author:** ![kunitoki](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kunitoki/32/15_2.png) [@kunitoki](https://forum.juce.com/u/kunitoki)\
**Post date:** [October 10, 2023, 6:15pm UTC](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151/18 "2023-10-10T18:15:53Z")

</div>

Also i forgot one important detail, your way of initialising and storing the “original” malloc/calloc/realloc friends is not thread safe, so you might have data races if any of those functions are called from several threads at the same time.

---

<div class="post-metadata">

**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\
**Post date:** [October 10, 2023, 6:33pm UTC](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151/19 "2023-10-10T18:33:39Z")

</div>

> [@kunitoki](#):
>
> Well i honestly don’t use `assert` anymore (at least not directly), i have my own `expect` function which is able to break into the debugger without crashing the app, so i could continue from there the debugging session instead of aborting.

Well, that inspection is more for me (‘developer of the library’) than you. What I was about to add anyway is a way to customize that function so you can inject `jassertfalse` (which isn’t aborting) there or your own assert function.

> [@kunitoki](#):
>
> See the c++17 overloads you are not overriding in [[here]](https://en.cppreference.com/w/cpp/memory/new/operator_new). I make use of those via `std::pmr` types for overly aligned containers to use for simd, so these overloads taking the alignment argument are called instead of the plain ones without it (via polymorphic\_allocator / memory\_resource).

Ah, thank you for this very important resource, I will add that shortly.

> [@kunitoki](#):
>
> Also i forgot one important detail, your way of initialising and storing the “original” malloc/calloc/realloc friends is not thread safe, so you might have data races if any of those functions are called from several threads at the same time.

Yes, this is a very important bug, thank you for reporting. 🙂

---

<div class="post-metadata">

**Author:** ![flyondonnie](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/flyondonnie/32/16968_2.png) [@flyondonnie](https://forum.juce.com/u/flyondonnie)\
**Post date:** [October 9, 2024, 1:34pm UTC](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151/20 "2024-10-09T13:34:43Z")

</div>

Hey Eyal. Does this checker support windows now? I’m guessing not but hope lives…

[Next page](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151.md?page=2)