Crash: Setting Enum Value

[dsokoloski]

Environment

• OS: MacOS 15.6.1 AS
• Version 1.9.24, 1.9.25b13, bleeding-edge [006c845]

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!

[benkuper]

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 ?

[dsokoloski]

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!

Chatigne-Project.tar.gz

crashlog.txt

[dsokoloski]

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

[dsokoloski]

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

[dsokoloski]

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.

[benkuper]

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

[benkuper]

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

[dsokoloski]

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. 👍

[eLandon]

Hi, I think I maybe facing a similar issue. I have similar crashes using the calendar module I posted a few weeks ago, I've been searching for weeks where the crash could come from in my module. As I need to deliver something stable urgently, I've been modifying my noisette recently and deported the calendar part using node-red and a websocket transmission, and just started seeing similar crashes happen. Both use enum to list events dynamically.
I'm using 1.25b13 on raspberry pi, shoul I try bleeding edge ?
Or should I avoid enums dynamic scripting ?
Anything I can do to help find the culprit ?

Crashlogs from both calendar module and node-red version are joined

crashlog-calendar module.txt

crashlog-nodered.txt

[benkuper]

The 2 crash logs are different : one comes from button bar on dashboard, the other form an update in the inspector.
Maybe it comes down to the same problem but different symptoms. Could you try and make it crash on windows or mac ?

[eLandon]

Thanks for the feedback, I have no mac, will try that on windows.

[christhell]

Hello All!
Yes, the 2 crashes are different but have asynchronous callbacks in common > UI resizing, notification, creation.
As an object deleted while an asynchronous event is pending or processed after destruction.
Asychronous synchronization management;)
Hoping to help.

[eLandon]

Here we have a crashlog on windows. Module versions might vary a bit from the rpi one, but conditions are the same : two calendar modules auto-updating, no human interaction.
The calendar module makes quite intensive use of dynamic ui creation, but I had similar crash removing all dynamic ui and storing all data in an object. The only values it still updates are 3 enums and a text input

crashlog.txt

[christhell]

The crash seems to occur during the creation of a TextButton in updateFromParameter, triggered by an asynchronous notification from an EnumParameter.
In fact, it seems that the automatic update of the 2 modules, even after removing the dynamic UI, does not prevent an asynchronous notification or update from arriving after a destruction or mutation. As a write on data read by the user interface.
Maybe it is necessary to kill the listeners completely and cancel the async in flight before?