Plugin Built With JUCE Crashing A Little Too Often

Audio Plugins
1

Hello,

We have an audio plugin built with JUCE that is crashing an awful lot, and I am having difficulty zeroing in on the cause.

A little background: We have been developing our plugin for 6+ years. Around 3 years ago, we integrated crash reporting using sentry native. Sentry is very informative, and at sentry.io, I see crash reports not only about our plugin, but since they all run in the same process, I see crash reports when the DAW crashes or other plugins crash. There isn’t much that I can do if the DAW crashes or other plugins crash, of course.

Recently, since JUCE 7 and our first release using JUCE 7, a crash in our plugin with the stack trace below has begun to dominate our Sentry reports.

juce::Component::internalMouseDown (juce_Component.cpp:2524)
juce::MouseInputSourceInternal::sendMouseDown (juce_MouseInputSource.cpp:124)
juce::MouseInputSourceInternal::setButtons (juce_MouseInputSource.cpp:204)
juce::MouseInputSourceInternal::handleEvent (juce_MouseInputSource.cpp:313)
juce::MouseInputSource::handleEvent (juce_MouseInputSource.cpp:610)
juce::ComponentPeer::handleMouseEvent (juce_ComponentPeer.cpp:90)
juce::NSViewComponentPeer::sendMouseEvent (juce_mac_NSViewComponentPeer.mm:785)
juce::NSViewComponentPeer::redirectMouseDown (juce_mac_NSViewComponentPeer.mm:661)
juce::JuceNSViewClass::callOnOwner<T> (juce_mac_NSViewComponentPeer.mm:2370)
juce::JuceNSViewClass::asyncMouseDown (juce_mac_NSViewComponentPeer.mm:2374)
__NSThreadPerformPerform

I believe that this is happening in the main/UI thread. The thing to notice is that all functions in this call stack, other than the system function __NSThreadPerformPerform are juce:: functions and there is not a single plugin specific function active when the crash occurs.

Now this does not necessarily mean that there is no error in the plugin specific parts, since some corruption could have occurred on a previous UI thread loop pass. But I am really at a loss to understand this so that I can correct it, and I can’t help think that this might be a bug in JUCE 7.

So I have two questions

  • Does anyone else have any reason to believe that their plugins crash in the JUCE only parts, independent of the plugin specific code.

  • When might the next version of JUCE after 7.0.5 be available? For a while (after JUCE 7.0.5 appeared) I built our plugin using JUCE from the development branch, and that made the frequency of the above crash go higher. So I reverted to the 7.0.5 release, and that improved things quite a bit. But not enough.

I can’t say that I understand this at all, so I am hoping that someone in the community here might have an idea.

Thanks for your time.

2

what Daw are you using? iv been having issues getting anything I make to work with FL studio specifically. same vst works in Ableton fine

3

Assuming this is JUCE 7.0.5 master, it looks like this line is a call to virtual function Component::mouseDown. The main reason I can think of for a crash on this exact line is something going wrong trying to resolve the correct implementation of mouseDown, which might happen if the component itself is destroyed during the call to internalMouseDown.

I don’t see anything obvious in the implementation of internalMouseDown that might cause the component to be destroyed, but maybe I’ve missed something. It might also be worth checking on other threads at the point of the crash, just in case some other thread is incorrectly destroying the component during the mouse handling.

4

Hi Reuk, Thanks for the reply. I believe that I have been pretty careful to never delete any component during the cycle when I am operating on it, and instead post a CallbackMessage to delete the component in a later cycle. But maybe I did just that, and don’t know it. This is a good idea to look for something like that.

But I don’t think that it is a second thread destroying the component just because I believe I have been careful to handle components only in the main thread.

Are there any plans to come out with an update to JUCE any time soon? I also want to use SystemStats::getUniqueDeviceID() (not related to my crash issue), and I know that this function has been updated on the development branch.

5

Hi Marquavious, Oh gosh, this is happening in lots of different DAWs: AUHostingServiceXPC_arrow (which is Logic out-of-process on Apple silicon, I believe), Logic (on Intel), Live, Reaper, Garage Band, and Studio One.

FL Studio seems to be the one DAW that I am not having a problem with, at least not yet.

6

Are you able to reproduce this crash yourself, or do you only see it in crash reports from users? If the former, what happens if you remove Sentry from the project?

7

Hi kerfuffle, I only see the crash in sentry crash reports. I have not been able to reproduce it myself. That sort of means that at this moment I am only guessing at a fix.

I can’t remove sentry unless I build a new production release and ship it. I am fairly certain that it is not sentry causing the crash, if that is what you are getting at.