Closed danra closed 6 months ago
Thanks for reporting I think I see what might be going wrong here I'll take a look tomorrow.
@danra unfortunately we're struggling to reproduce this one. It's a bit of a head scratcher, despite my initial enthusiasm, I'm having a hard time to see how this assertion ever gets hit but more curiously how the commits in question could be the cause. Although they touch the TimerThread, the TimerThread was always created by the first Timer being created and it always called triggerAsyncUpdate()
in its constructor so the order of events should be identical. The only conclusion is some kind of race between this and whatever creates the MessageManager (which we're looking into).
Is there potentially anything special / specific about how the plugin is being loaded? maybe you could share a project that always asserts for you when it's loaded? if you're able to try and reproduce this on another machine that could also be a useful data point too.
Thanks.
the TimerThread was always created by the first Timer being created
Are you sure? Looking at the code, and verifying with a breakpoint in TimerThread
ctor, prior to https://github.com/juce-framework/JUCE/commit/47be26deedf788f1c769be575397a6d5de6af999 I do not see it constructed just by constructing a timer. It looks like it only gets constructed when a timer is first added. Whereas after this commit, TimerThread
does get immediately constructed along with the Timer
construction, as evident in the stack trace attached above. (Maybe that's undesirable new behavior regardless of the assert).
Is there potentially anything special / specific about how the plugin is being loaded? maybe you could share a project that always asserts for you when it's loaded?
I'm actually getting this prior to any project loading - just every time I open Logic 10.8.1 (Rosetta) with the debugger attached, at this stage:
@danra apologies you're absolutely right I thought I remembered we were adding timers in the constructor. I guess this means the change in the Timer has changed user requirements from requiring a MessageManager exists when you call startTimer(), to requiring a MessageManager exists when any object inheriting from Timer is constructed.
I'll give this some thought. Unfortunately I was certainly having issues debugging a Rosetta build, some break points weren't hitting and I even had a crash that didn't stop the debugger.
@szarvas has kindly taken this up and has been taking a look.
Thank you for reporting.
This has been fixed on develop
https://github.com/juce-framework/JUCE/commit/00e96e7779b9cf206b167da0319a96e001ad133f
Detailed steps on how to reproduce the bug
0) Workaround #1307 by reverting 60df98202ef57de8ab38dbd82932e01a9fdd0ec3 to get local copy step to work on Logic 1) Open ARAPluginDemo example in Projucer 2) Set target macOS to 13 (resolves JUCE's
static_assert
on the new linker on Xcode 15.0.1) 4) Save to Xcode project, build, and run Logic Pro 10.8.1 (Rosetta) with debugger attached. 5) Bug: Assertion failure on loadThis is apparently due to the recent
Timer
changes in 005040da771c9300e2c6a0ad2d8aab40e631a6f6 and 47be26deedf788f1c769be575397a6d5de6af999. Reverting these two commits resolves the issue.What is the expected behaviour?
No assertion failure
Operating systems
macOS
What versions of the operating systems?
14.1.1
Architectures
x86_64
Stacktrace
Plug-in formats (if applicable)
AU
Plug-in host applications (DAWs) (if applicable)
Tested on Logic Pro 10.8.1 (Rosetta)
Testing on the
develop
branchThe bug is present on the
develop
branchCode of Conduct