# Realloc() crashing

**URL:** <https://forum.juce.com/t/realloc-crashing/40519>\
**Category:** General JUCE discussion\
**Created:** [July 3, 2020, 1:57pm UTC](https://forum.juce.com/t/realloc-crashing/40519 "2020-07-03T13:57:45Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Franchovy](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/franchovy/32/9118_2.png) [@Franchovy](https://forum.juce.com/u/Franchovy)\
**Post date:** [July 3, 2020, 1:57pm UTC](https://forum.juce.com/t/realloc-crashing/40519/1 "2020-07-03T13:57:45Z")

</div>

Hi,

I’m using `realloc()` as part of a buffer reassignment for an `AudioProcessor`, and I get a crash (sometimes in a totally different area, like `realloc()` downstream of `repaint()`) from the reallocation code.

I put the reallocation in a message thread using `AsyncUpdater`, but this did not solve my issue. Is there a way to check for a lock before running reallocation code? I can’t see what else the issue could be.

Tips for best practice are appreciated!!

Edit: crash details

> **Summary**
>
> This is the stack trace I’ve got on the crash:
> 
> ```
> __GI_raise 0x00007f179af1e081
> __GI_abort 0x00007f179af09535
> __libc_message 0x00007f179af5fdc8
> malloc_printerr 0x00007f179af6632a
> _int_realloc 0x00007f179af6a25c
> __GI___ libc_realloc 0x00007f179af6b3cb
> juce::HeapBlock<std::complex<float>, false>::realloc<int> juce_HeapBlock.h:293
> STFT::updateFftSize STFT.h:123
> 
> ```
> 
> and this is the `realloc()` line that is crashing (not the actual `throw()`):
> 
> ```
> /** Re-allocates a specified amount of memory.
> The semantics of this method are the same as malloc() and calloc(), but it
> uses realloc() to keep as much of the existing data as possible.
> */
> template <typename SizeType>
> void realloc (SizeType newNumElements, size_t elementSize = sizeof (ElementType))
> {
> data = static_cast<ElementType*> (data == nullptr ? std::malloc (static_cast<size_t> (newNumElements) * elementSize)
> : std::realloc (data, static_cast<size_t> (newNumElements) * elementSize));
> ^^^ - crashes here
> throwOnAllocationFailure();
> }
> 
> ```

---

<div class="post-metadata">

**Author:** ![Franchovy](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/franchovy/32/9118_2.png) [@Franchovy](https://forum.juce.com/u/Franchovy)\
**Post date:** [July 3, 2020, 2:31pm UTC](https://forum.juce.com/t/realloc-crashing/40519/2 "2020-07-03T14:31:38Z")

</div>

Sweet, I got it.

Adding:

```
CriticalSection lock; // .h

const ScopedLock sl (lock); // .cpp - at start of reallocation method

```

seems to solve the issue

---

<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:** [July 3, 2020, 2:36pm UTC](https://forum.juce.com/t/realloc-crashing/40519/3 "2020-07-03T14:36:08Z")

</div>

So you are reallocating asynchronous on the message thread and accessing the `HeapBlock` on another thread (the audio thread?) simultaniously? If it’s like that than this sounds like a bad design. However, a good solution to this depends on the context.

A simple one is to create a `CriticalSection` object that has to be locked by a `ScopedLock` for every kind of access to the `HeapBlock`. For many use-cases this is a good idea, but in case you are working on the audio thread, this could lead to the audio thread being blocked my the message thread that holds the lock but has a lower priority. This would be called a priority inversion and can lead to audio dropouts. In this case, I’d advise you to have two heap blocks, one that is accessed from the audio thread and one that is not. You can then safely resize the inactive block on the message thread or any other and copy over the content from the active one. When all is done, you can simply swap them, which is a short operation

---

<div class="post-metadata">

**Author:** ![Franchovy](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/franchovy/32/9118_2.png) [@Franchovy](https://forum.juce.com/u/Franchovy)\
**Post date:** [July 3, 2020, 2:54pm UTC](https://forum.juce.com/t/realloc-crashing/40519/4 "2020-07-03T14:54:11Z")

</div>

Yes, thank you!  
Previously I had missed that I was using this reallocation directly on the audio thread, and yes, it caused issues. I had moved all the reallocation to the message thread, but still had the crash I originally posted.

The `CriticalSection` and `ScopedLock` solved the issue, thanks for pointing it out! Although I originally got the result straight from the open-sourced code I’m using 😉

Thanks for pointing out the swapping operation as well. It may come in useful, although, in my case right now - when `CriticalSection`/`ScopedLock` is used, does this prevent the AudioThread from trying to access the heaps being modified? (to avoid mid-resize accesses)

---

<div class="post-metadata">

**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\
**Post date:** [July 3, 2020, 2:59pm UTC](https://forum.juce.com/t/realloc-crashing/40519/5 "2020-07-03T14:59:13Z")

</div>

It prevents it in a nasty way: it will let the processBlock wait until you are finished doing your allocation!

That is exactly what PluginPenguin described as priority inversion.

An allocation can take an infinite amount of time, because the memory management needs to lock as well, so you have no idea for whom you are actually waiting.

---

<div class="post-metadata">

**Author:** ![Franchovy](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/franchovy/32/9118_2.png) [@Franchovy](https://forum.juce.com/u/Franchovy)\
**Post date:** [July 3, 2020, 3:00pm UTC](https://forum.juce.com/t/realloc-crashing/40519/6 "2020-07-03T15:00:09Z")

</div>

Alright, that makes sense. Thanks for pointing it out!