benkuper
Crash: Setting Enum Value
Environment
- OS: MacOS 15.6.1 AS
- Version 1.9.24, 1.9.25b13, bleeding-edge [006c845c72d8de486f7f4ede88bbad9b0466e087]
Describe the bug It's difficult to know exactly what's happening because it's intermittent; appears to be a timing issue. In summary, I have a mapping that updates an enum when I set the value of another Custom Variable. I can test for hours and everything is fine, and then for apparently no obvious reason, I get the following stack trace dumped to the log (>= v1.9.25), or the app completely crashes (< v1.9.25):
16:44:18 CrashHandler A Crash happened !
0 Chataigne 0x0000000102dc455c _ZN4juce11SystemStats17getStackBacktraceEv + 72
1 Chataigne 0x0000000103268784 _ZN17CrashDumpUploader11handleCrashEi + 2736
2 Chataigne 0x0000000102dc4658 _ZN4juceL11handleCrashEi + 16
3 libsystem_platform.dylib 0x00000001929e96a4 _sigtramp + 56
4 Chataigne 0x0000000102fddb0c _ZN4juce12ListenerListI17ParameterListenerNS_5ArrayIPS1_NS_20DummyCriticalSectionELi0EEEE20callCheckedExcludingIZNS6_20callCheckedExcludingINS6_19DummyBailOutCheckerEJP9ParameterEJSB_EEEvS3_RKT_MS1_FvDpT0_EDpOT1_EUlRS1_E_S9_EEvS3_RKT0_OSC_ + 316
5 Chataigne 0x0000000102fdc4a8 _ZN9Parameter8setValueEN4juce3varEbbb + 508
6 Chataigne 0x0000000102feb108 _ZN13EnumParameter16setValueWithDataEN4juce3varE + 236
7 Chataigne 0x0000000102a9c050 _ZN26GenericControllableCommand15triggerInternalEi + 1032
8 Chataigne 0x0000000102785050 _ZN18ConsequenceManager10triggerAllEi + 204
9 Chataigne 0x0000000102770004 _ZN6Action19triggerConsequencesEbi + 104
10 Chataigne 0x000000010276f768 _ZN6Action27onContainerTriggerTriggeredEP7Trigger + 220
11 Chataigne 0x0000000102faf1a8 _ZThn24_N21ControllableContainer16triggerTriggeredEP7Trigger + 68
12 Chataigne 0x000000010309bf18 _ZN7Trigger7triggerEv + 456
13 Chataigne 0x0000000102784c78 _ZN26ConsequenceStaggerLauncher3runEv + 1244
14 Chataigne 0x0000000102d9d9cc _ZZN4juce6Thread18createNativeThreadENS0_8PriorityEEN4$_288__invokeEPv + 492
15 libsystem_pthread.dylib 0x00000001929afc0c _pthread_start + 136
16 libsystem_pthread.dylib 0x00000001929aab80 thread_start + 8
To Reproduce I just keep cycling through my Cues. Appears to be "random", or a timing issue.
Let me know if I should attach my noisette.
Expected Behaviour No crashes.
Additional Context As a software developer I'm willing to debug myself, but I can't get the project to compile under Xcode and wasn't able to find any documentation describing how to configure my environment. I'm willing to contribute to the debugging if I could get to a point were I could successfully compile.
I've used Chataigne for a community theatre production last year and it was rock solid. This time my noisette is more complex as I understand it better and our automation requirements are more demanding. It's great software, I'm likely (hopefully) just doing something wrong?
Any suggestions are very much appreciated!
Hello, Unfortunately it's likely not your fault :) Could you attach the file ? I can maybe have a look tomorrow if that's reproducible in my side.
Also, the readme on github should be enough to get you compiling and running the app, what problem do you encounter ?
Ben,
Thanks for the quick reply!
I've attached my project file. FWIW, I just completed a 4 hour session with Chataigne, zero crashes! I made a lot of changes, so perhaps I inadvertently fixed the problem -- if that's even possible.
While I was attaching the project file, I found a crashlog.txt with a timestamp that corresponds to the last crash today. I attached it as well.
Also, the readme on github should be enough to get you compiling and running the app, what problem do you encounter ?
Oops, didn't read the README!
The problem was that I didn't do this:
Chataigne is using a modified version of JUCE. So you first need to compile the Projucer from the modified version of JUCE instead of downloading JUCE
I will retry in the morning... Thanks again for your help!
Ben,
I was able to build successfully. Running Chataigne from the debugger, my project fails the following JUCE assertions whenever I trigger a cue:
- JUCE_ASSERT_MESSAGE_MANAGER_IS_LOCKED
- JUCE_ASSERT_MESSAGE_MANAGER_IS_LOCKED_OR_OFFSCREEN
Most of them appear to come from:
Chataigne`CustomLoggerUI::clearLogger(this=0x00000001531c5400) at CustomLoggerUI.cpp:288:20
...but not all. I can provide backtraces if that's helpful. When I detach the cue executes fine... and the application performs normally.
Are these assertions "dangerous"? The comments above them seem ominous regarding thread-safety:
// if component methods are being called from threads other than the message
// thread, you'll need to use a MessageManagerLock object to make sure it's thread-safe.
UPDATE 1:
All of the assertions I receive from triggering conductor cues go away if I disable "Stagger" (set back to 0).
UPDATE 2:
I replaced the two jassert()s to cerr lines, and now I can run staggered consequences from the debugger but I receive the following stack traces in the console from the "Stagger Launcher" thread. It appears that this thread is making unsafe (unlocked) API calls to the UI API? Everything keeps running as if nothing happened, but is it possible that if the conditions are just so that such calls could crash the application? ¯\(ツ)/¯
Main Thread Checker: UI API called on a background thread: -[NSWindow isMiniaturized]
PID: 14044, TID: 3050339, Thread name: Stagger Launcher, Queue name: com.apple.root.default-qos.overcommit, QoS: 0
Backtrace:
5 Chataigne 0x0000000105da6d2c _ZNK4juce19NSViewComponentPeer11isMinimisedEv + 28
6 Chataigne 0x0000000105ca1b98 _ZNK4juce9Component9isShowingEv + 136
7 Chataigne 0x0000000105ca1b64 _ZNK4juce9Component9isShowingEv + 84
8 Chataigne 0x0000000105ca1b64 _ZNK4juce9Component9isShowingEv + 84
9 Chataigne 0x0000000105ca1b64 _ZNK4juce9Component9isShowingEv + 84
10 Chataigne 0x0000000105ca1b64 _ZNK4juce9Component9isShowingEv + 84
11 Chataigne 0x0000000105ca1b64 _ZNK4juce9Component9isShowingEv + 84
12 Chataigne 0x0000000105ca1b64 _ZNK4juce9Component9isShowingEv + 84
13 Chataigne 0x0000000105ca1b64 _ZNK4juce9Component9isShowingEv + 84
14 Chataigne 0x0000000105ca1b64 _ZNK4juce9Component9isShowingEv + 84
15 Chataigne 0x0000000105ca1b64 _ZNK4juce9Component9isShowingEv + 84
16 Chataigne 0x0000000105ca1b64 _ZNK4juce9Component9isShowingEv + 84
17 Chataigne 0x0000000105cb4a6c _ZN4juce9Component9setBoundsEiiii + 440
18 Chataigne 0x0000000105d50018 _ZN4juce7ListBox12ListViewport17updateVisibleAreaEb + 264
19 Chataigne 0x0000000105cd7f30 _ZN4juce7ListBox13updateContentEv + 308
20 Chataigne 0x0000000106439da4 _ZN14CustomLoggerUI11clearLoggerEv + 76
21 Chataigne 0x0000000105313a5c _ZN19ChataigneLogCommand15triggerInternalEi + 324
22 Chataigne 0x0000000104b66a80 _ZN11BaseCommand7triggerEi + 152
23 Chataigne 0x0000000104c291c0 _ZN18BaseCommandHandler14triggerCommandEi + 76
24 Chataigne 0x0000000104c66e00 _ZN11Consequence14triggerCommandEi + 84
25 Chataigne 0x0000000104c6a064 _ZN26ConsequenceStaggerLauncher13processLaunchEPNS_6LaunchE + 656
26 Chataigne 0x0000000104c69a40 _ZN26ConsequenceStaggerLauncher3runEv + 448
27 Chataigne 0x00000001059aff90 _ZN4juce6Thread16threadEntryPointEv + 340
28 Chataigne 0x00000001059b043c _ZN4juce21juce_threadEntryPointEPv + 24
29 Chataigne 0x0000000105a22d10 _ZZN4juce6Thread18createNativeThreadENS0_8PriorityEENK3$_0clEPv + 148
30 Chataigne 0x0000000105a22c70 _ZZN4juce6Thread18createNativeThreadENS0_8PriorityEEN3$_08__invokeEPv + 28
31 libsystem_pthread.dylib 0x000000010c1c508c _pthread_start + 136
32 libsystem_pthread.dylib 0x000000010c1cef54 thread_start + 8
Ben,
I also receive these warnings when I load my project, but I can't find any "broken" links and all triggers of the following sequences work just fine. Red herring?
10:16:16 CustomLoggerUI Chataigne v1.9.25b13 : (17/10/25 (07:52))
10:16:17 Engine Session loaded in 1.304s
10:16:17 Target Link is broken : /sequences/hudHide
10:16:17 Target Link is broken : /sequences/loadingMusic/layers/loadingDock
10:16:17 Target Link is broken : /sequences/loadingMusic
10:16:17 Target Link is broken : /sequences/loadingMusciFadeOut
10:16:17 Target Link is broken : /sequences/loadingMusic/layers/loadingDock
10:16:17 Target Link is broken : /sequences/loadingMusic/layers/dollFactory
10:16:17 Target Link is broken : /sequences/loadingMusic
10:16:17 Target Link is broken : /sequences/mobileMicFaderDown
10:16:17 Target Link is broken : /sequences/startVideoCall
10:16:17 Target Link is broken : /sequences/startVideoCall
10:16:17 Target Link is broken : /sequences/startVideoCall
10:16:17 Target Link is broken : /sequences/startVideoCall
10:16:17 Target Link is broken : /sequences/startVideoCall
10:16:17 Target Link is broken : /sequences/startVideoCall
10:16:17 Target Link is broken : /sequences/startVideoCall
10:16:17 Target Link is broken : /sequences/startVideoCall
10:16:17 Target Link is broken : /sequences/loadingMusic/layers/loadingDock
10:16:17 Target Link is broken : /sequences/hudHide
10:16:17 Target Link is broken : /sequences/lowerThirdShow
10:16:17 Target Link is broken : /sequences/loading
10:16:17 Target Link is broken : /sequences/enterLocation
10:16:17 Target Link is broken : /sequences/enterLocation
10:16:17 Target Link is broken : /sequences/enterLocation
10:16:17 Target Link is broken : /sequences/enterLocation
10:16:17 Target Link is broken : /sequences/enterLocation
10:16:17 Target Link is broken : /sequences/enterLocation
10:16:17 Target Link is broken : /sequences/enterLocation
10:16:17 Target Link is broken : /sequences/enterLocation
10:16:17 Target Link is broken : /sequences/updateScore
10:16:17 Target Link is broken : /sequences/mobileMicFaderUp
10:16:17 Target Link is broken : /sequences/lowerThirdShow
10:16:17 Target Link is broken : /sequences/hudShow
10:16:17 Target Link is broken : /sequences/loading
10:16:17 Target Link is broken : /sequences/hudHide
10:16:17 Target Link is broken : /sequences/loading
10:16:17 Target Link is broken : /sequences/loadingMusic
10:16:17 Engine Session loaded in 1.84s
Ben,
I have no idea if this is the right place to do this, but I found that the following diff fixes the assertions:
diff --git a/Source/Common/Processor/Action/Consequence/Consequence.cpp b/Source/Common/Processor/Action/Consequence/Consequence.cpp
index 7f09d78e..ee226cdf 100644
--- a/Source/Common/Processor/Action/Consequence/Consequence.cpp
+++ b/Source/Common/Processor/Action/Consequence/Consequence.cpp
@@ -24,5 +24,8 @@ Consequence::~Consequence()
void Consequence::triggerCommand(int multiplexIndex)
{
if (!enabled->boolValue() || forceDisabled) return;
+ MessageManagerLock mml (Thread::getCurrentThread());
+ if (! mml.lockWasGained())
+ setWarningMessage("Failed to aquire messaging manager lock.");
BaseCommandHandler::triggerCommand(multiplexIndex);
}
...and what the consequences are of holding this lock for long running commands? FWIW, in my project there have been no noticeable issues.
This is not where it should be fixed, as this is only one call triggering the logger amongst many, but I'll check where this should actually be fixed. Thank you for this
Also, none of the warnings and assertions you hit are the cause of your problem :) this is deeper unfortunately, but the new versions of Chataigne should at least have a different data flow for this and hopefully fix those "random" crashes
Ben,
You're right about that. I haven't had any crashes since. Other than the "hitching" I notice during sequence playback from my locking patch, stability is great. 👍