# 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:** 1\
**Showing post:** 3

<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.

---

_[View the full topic](https://forum.juce.com/t/fr-option-for-assert-on-audio-thread-allocation-or-syscall/58151)._