Almost every 3rd party plugin causes a JUCE Timer crash report to be generated in the Console app upon quitting Logic 11.0.1. Is there any news on this at all? It seems this will never be addressed and is starting to feel like a ‘norm,’ sadly.
Do you see this problem with any of the JUCE examples built from the current develop branch?
Without knowing exactly which plugins are active in the project, the version(s) of JUCE used to build those plugins, and detailed steps to reproduce the problem, there’s not much we can do.
I assume you’re referring to plugins built with JUCE here. If these plugins are built using an older version of JUCE, then it’s possible that any issues you’re seeing have already been fixed on the develop branch - but of course, each plugin will need to be rebuilt with a new version of JUCE in order to incorporate these fixes.
I will add that I’ve spoken with a number of developers and users, and with the latest version of JUCE I am not aware of any existing issues with the timer.
I think the issues were addressed back in December. That being said most of the reports I recall were not while closing Logic, maybe my memory has failed me.
Can you share some crash logs? I’m happy to share a debug plugin with you that uses the timer extensively to see if you are able to reproduce the problem with the latest version of JUCE.
I also spoke to a user that later came back to say that at least anecdotally some software that came with a backup UPS system appeared to be causing the issue to occur more frequently for them, it’s unclear how or why that would be the case though.
We’ve also only seen reports of these Timer crashes in Logic, and as there is nothing special about the Timer running in Logic it’s extremely unclear why this would be the case.
Personally I’ve never been able to reproduce the issue locally, but if you have more information to share I’m happy to try again.
I will share some logs.
1 Like
I was going to upload some logs for you, but it says that new users cannot do that.
Can you make it so that I can upload attachments, please?
Can some admin please make it so that I can upload attachments? Thank you.
Please could you email the logs to info@juce.com?
Sent, thanks.
@ZenithSounds thanks I can see your email I’ve had a look through the logs you sent. Both seem to happen in the same plugin (MODO BASS 2) is this the only plugin that is crashing for you?
This does look like a crash we have seen in the past but to the best of our knowledge is fixed in the latest versions of JUCE. However, manufacturers will need to update the version of JUCE they are using, deploy that version, then users will have to download and install those updates to see this resolved.
I had an attempt at recreating the issue again by creating a plugin that fires a timer at 1ms intervals, I inserted 1000 instances of the plugin in a session, opened the session and quit the application multiple times, no issues for me. That being said I’ve tried this with older versions of JUCE without any luck either.
1 Like
Thanks for all this info. No, this is not the only plugin experiencing this. There are lots. I will assume all the ones that throw the crash logs are for the same reason. This would require a lot of developers to do updates. I won’t hold my breath for that one. 
I will continue to send more crash logs as they occur with different plugins and will also share them with the plugin developers.
Does JUCE also let developers know they need to update their code, or is this totally up to them to be proactive about?
Thanks
Unfortunately there is no other way. I will say that Logic is the only DAW to date where we’ve seen this crash including from developers who auto collect crash logs via analytics which is highly suggestive that Logic may have some part to play in the issue, but it’s too difficult to say how or why that is the case without a developer being able to reproduce the issue.
Customers are notified about major updates via email but it can be difficult to know if customers need to update as they could be using an open source licence or they may have a custom version of JUCE in which they’ve made their own changes. As we don’t have access to their source code we don’t know exactly what version of JUCE they are running or if their products will be impacted by the issue.
We can obviously reach out to companies individually and there are conferences throughout the year where we can catch up with developers in person too. This gives us an opportunity to find out if there is anything we can do to help. However, there are various reasons why it might be difficult to update and some of those reasons may not be directly related to JUCE.
1 Like
Logic Pro/GarageBand and MainStage are probably also the only Audio Unit hosts, which require plugins to be out-of-process. That means they are hosted by macOS, not the applications itself.
BTW: Apple informed all ProAudio Seed developers yesterday about a new Logic Pro seed build, which does allow developers to try out the next version of Logic Pro and Sequoia, before they ship. This seed build has AU and Lua-scripting changes and fixes.
1 Like
The latest Pro Tools when caching plugins at startup also loads them out of process… but Logic also doesn’t destroy plugins when you close a session. I had to change my shutdown code to handle the way Logic destroys plugins… the order of object destruction became much more critical.
Rail
Logic Pro doesn’t destroy them, because certain plugins take a significant time at first launch. By not destroying them and instead recycling them, this is faster for the user.
And yes, you need to test your plugins in different hosts.
I found the Juce Timer MODO BASS crash in our Apple Silicon crashlogs at Apple.
What happens seems to be: -[AUHostingService closeHost:] is called and because of that the plugin has a bunch of C++ destructors being called. During the execution of these destructors, it crashes in the “JUCE Timer” thread.
Seems a very clear case: the timer is still firing while the plugin is in the process shutting down. Classic race condition: the timer tries to access some data, which are already gone.
This kind of race condition during closing is extremely common with many Audio Units. I can see an enormous number of these crashes.
@mfritze thanks for sharing. It’s a touch more complicated because the JUCE Timer thread doesn’t actually run any user code it just adds messages to a queue that runs the user code on the main thread. It seems the Timer thread is probably trying to add messages to a queue that has been deleted, in theory that shouldn’t be possible because the MessageQueue is very clearly and explicitly deleted after the TimerThread, and the thread itself is stopped in the destructor of the TimerThread.
A little while ago I looked into it and came up with two theories
- The TimerThread is somehow recreated immediately after being destroyed
- The TimerThread continues running beyond the lifetime of the MessageQueue, this might happen if for one reason or another the TimerThread failed to stop within 4000ms during the TimerThread destructor
I implemented some work arounds for these so there were better guarantees about lifetimes, and to the best of my knowledge they do appear to have stopped the crashes. So I think we can safely say JUCE was primarily at fault.
When I said “highly suggestive that Logic may have some part to play in the issue” I probably should have taken more time to emphasise “may” in that sentence.
Of all the crash logs I’ve seen (~60) every single one has been in Logic. I have not seen any from another DAW. This is very surprising, although I accept that JUCE is at fault, anecdotally at least, it would appear that something about Logic makes one of the above two conditions more likely to occur. I think your observation about plugins being hosted out of process is a good one, but I still can’t think why that would increase the chance of this crash. I think it’s worth adding that there could well be something that some of these specific plugins are doing, but it’s very hard to say for certain.
That being said I’m yet to encounter a developer who is able to reproduce the issue. Whereas, it seems some users can reproduce the issue extremely reliably. I think the is what has lead to frustration from some end users. So maybe there is something specific about the environments that also makes it more likely?
I hope that all make sense and @mfritze I really appreciate you taking to time to look at this.
Thanks for your response. I concur that I have never seen this issue in any other DAW, only Logic. Also, I do not understand why any developer would say they cannot reproduce this. I have found that if a plugin exhibits this behavior it will happen every time Logic is closed. All any developer has to do is look in the Console app on their Mac after closing Logic and the crash log will get immediately generated. You can even have the Console app open while closing Logic and see the log generated in real time. It happens without fail.
As explained above I’ve tried running 1,000s of instances in a session with zero crashes. If this actually happened 100% of the time, for 100% of users, then developers who are collecting crash reports would be inundated with many 1,000’s of these crashes. If I check my console, I have zero crashes relating to Logic.
To prove the point I downloaded and installed MODO BASS 2, created a session with 1000 tracks each running the plugin, made sure at least a couple of the UIs were open, hit play, and quit logic. No crashes.
Ahhhh, ok. I think I understand why this is being misunderstood. I apologize for not being clear enough. No actual ‘crash’ of Logic occurs. Logic does not go down. All that happens is a crash log is generated in the Mac Console app. You have to open the Console application and look at the logs after closing a Logic project to see the generated crash logs. Is that clear now?
Also, try just one instance of the plugin. You do not need but one.