I have reported this to the developer, Cradle. I always report these JUCE issues to the plugin developers, but they just really do not seem to care.
It only happens with Logic because of AU obviously, so maybe that is just not enough of an incentive for them to update.
You would be shocked how many of them act like they have no clue what I am even referring to, even though I spell it out for them. Then they try to blame Logic. They often insist Logic needs to be updated, not their plugin…
There are no new changes planned for the Timer to address anything relating to this issue specifically. @Verbonaut you sent me some crash logs (thanks for that) but currently they are the only ones I have that I know that may be with all the known fixes applied. I’ve not heard of the same crashes occurring from anyone else who is up to date… yet. I’m also waiting to hear back from some other developers who are in the process of updating and have beta testers who are apparently seeing this issue reliably.
Sorry, I wasn’t meaning to be dismissive I just want to be absolutely certain these issues are occurring with all the fixes in place or I’m potentially chasing fixes that have already been applied.
Thanks for reporting.
I realise it’s frustrating but there’s lots of reasons developers can’t update so quickly.
You may not be talking to developers directly and I’m sure there are lots of other issues and concerns they are dealing with. It does seem to be a very small percentage of users impacted by this, however for some users the impact is relatively severe. So it’s likely it’s not top of their pile, if they are a relatively small development team they may not have even heard of the issue.
I’m not going to put the blame on Logic. There is however a strange relationship between these errors and Logic hat I haven’t been able to understand. It is the only host that seems to suffer from this, BUT I must stress that at the end of the day, JUCE code is what is crashing so I do think updating JUCE should fix the issue even if it only happens in one DAW 
.
I’m developing a macOS Host for VST3 plugins and I’m getting a crash in “Juice Timer” when my app quits. (I have only plugin that I’m sure uses JUCE).
You said above you said “we changed the name of the thread to include the JUCE version number.” The plugin that’s crashing on me just says “JUCE Timer” in the XCode call stack view – no version number shown.
So can I assume the version of JUCE used by the plugin is the one with the known issue?
Finally, based on the nature of the JUCE bug, is there any way to avoid the crash that you know of? I tried looping in the main run loop for 1 second before quitting to see if that would give the plugin time to “settle down”, but my host app still randomly crashes.
Thanks in advance,
Mark
It will depend what version of JUCE is being used.
It’s likely, but not definite, the change to the thread name came a little after the fixes so there are some versions of JUCE in-between that have the proposed fixes without the thread name change.
To be honest this would be the first case of this happening in a DAW other than Logic and therefore also in a format other than AU. Could you please either privately send me some crash logs or share them on here.
What’s more, I think you would be the first developer to see this issue so it would be great if you’re able to help debug the issue to give us more information. The fixes that were applied were all speculative based on crash logs. If you can share any crash logs you have I might be able to suggest what I think could be happening.
OK, I think I’ve worked around the crash and isolated the reason for it.
I’ll start with the specific plugin that causes the problem, which is the free Magic7 reverb from Wave Alchemy. It definitely has “JUCE Timer” as the name of the thread that’s crashing, so that would seem to indicate that it is the older version of the framework before versions numbers were added.
The first problem was that I had a shared_ptr reference to my custom AudioClient, which is based on the AudioClient code from the VST3 SDK. Because of this, the component’s setActive(false) was never being called, d’oh! So that one’s on me, not the JUCE framework.
Addressing this problem unfortunately did not prevent the crash in JUCE Timer. Here’s what did.
I mentioned in my previous post that I had tried sitting in a loop just before program exit to work around the issue, but that it still crashed.
while (get_current_time_mS() < time_100mS_in_the_future) {
[[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow: 50 / 1000.0]];
}
the key was changing the code to something like this:
while (get_current_time_mS() < time_100mS_in_the_future) {
usleep(50 * 1000);
}
Now one more clue which may help you, but which applies to almost no developers other than me. (Which may be why it’s a clue.)
My app uses a hand-crafted cross-platform framework for macOS and Windows. For various reasons, this meant I had to make a custom version of NSApplicationMain(argc, argv) which is usually called from main.m to run the program.
What I am not doing in that custom function was calling NSApplication’s terminate:(id)sender method because it has no bearing on the functionality of my framework.
Maybe the timer is relying on the ’ NSApplicationWillTerminateNotification’ notification sent by the terminate method? Or else it is otherwise relying on NSApplication’s terminate:(id)sender method being called?
All of that said, I added a call to [[NSApplication sharedApplication] terminate:nil] just before my program exited, and it did not prevent that crash in the JUCE Timer thread. I still needed the delay loop described above.
Hope that helps!
Mark
