Beam consistently crashing Max

Yikes! My finished Beam patcher works just fine if I control it manually by scrolling a number box. But as soon as I connect the output of my sensor input module, or even use a simple [cycle~ 0.2] to fade a couple of colours up/down, Max quits on the spot.

Here’s the first part of the crash log, with the crashed thread, in case you can make sense of it. It’s the same every time (and it’s been lots of times as I try to track this down). I’ll attach the version of the patch I’m using to test this in a reply to this message. The green outlined subpatch contains the Arduino input, which won’t be much use to you, so I’ve added a simple LFO with a switch to connect it. If you wildly scroll the number box up/down using the mouse it all works fine. If you connect the LFO it will run for a short time and then quit Max.
I’m trying this on Max8.5.6 as 8.5.7 & 8.6 both have the updated [serial] object which completely fails to output any data on my Mac.
Mac mini M2 Pro 32GB, Sonoma 14.2.1

Translated Report (Full Report Below)

Process: Max [1360]
Path: /Applications/
Identifier: com.cycling74.Max
Version: 8.5.6 (13186257284) (8.5.6)
Code Type: X86-64 (Translated)
Parent Process: launchd [1]
User ID: 501

Date/Time: 2024-01-20 14:14:23.8295 +0000
OS Version: macOS 14.2.1 (23C71)
Report Version: 12
Anonymous UUID: 8B00F36C-2128-AA4A-8F25-9B09E5708F25

Time Awake Since Boot: 8100 seconds

System Integrity Protection: enabled

PC register does not match crashing frame (0x0 vs 0x1500C1D1D)

Crashed Thread: 0 CrBrowserMain Dispatch queue:

Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000008
Exception Codes: 0x0000000000000001, 0x0000000000000008

Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process: exc handler [1360]

VM Region Info: 0x8 is not in any region. Bytes before following region: 140723191595000
mapped file 7ffcabd8c000-7ffcd47a4000 [650.1M] r-x/r-x SM=COW …t_id=34d1a2bd

Error Formulating Crash Report:
PC register does not match crashing frame (0x0 vs 0x1500C1D1D)

Thread 0 Crashed:: CrBrowserMain Dispatch queue:
0 beam.lib 0x1500c1d1d showsync::beam::FixtureFrame::merge(std::__1::vector<std::__1::pair<std::__1::shared_ptrshowsync::beam::FixtureFrame, float>, std::__1::allocator<std::__1::pair<std::__1::shared_ptrshowsync::beam::FixtureFrame, float>>> const&, std::__1::unordered_map<Symbol, float, std::__1::hash, std::__1::equal_to, std::__1::allocator<std::__1::pair<Symbol const, float>>> const&, Symbol const&, bool) + 125
1 beam.lib 0x1500c3b21 showsync::beam::Frame::merge(std::__1::vector<std::__1::pair<std::__1::shared_ptrshowsync::beam::Frame, float>, std::__1::allocator<std::__1::pair<std::__1::shared_ptrshowsync::beam::Frame, float>>> const&, Symbol const&, bool) + 3665
2 beam.lib 0x150070ab2 callprocess(c74::max::_multinode*) + 1106
3 Max 0x100a4316a linklist_funall_imp + 378
4 Max 0x100a00506 object_method_imp + 326
5 Max 0x100a5f1b9 object_method + 393
6 beam.lib 0x15007637d showsync::beam::MaxInstance::timerCallback() + 157
7 beam.lib 0x1502067fd juce::timer::TimerThread::callTimers() + 221
8 beam.lib 0x15020a879 juce::MessageQueue::runLoopCallback() + 57
10 CoreFoundation 0x7ff8164ff779 __CFRunLoopDoSource0 + 157
11 CoreFoundation 0x7ff8164ff548 __CFRunLoopDoSources0 + 215
12 CoreFoundation 0x7ff8164fe1b8 __CFRunLoopRun + 919
13 CoreFoundation 0x7ff8164fd859 CFRunLoopRunSpecific + 557
14 HIToolbox 0x7ff82129b9d9 RunCurrentEventLoopInMode + 292
15 HIToolbox 0x7ff82129b7e6 ReceiveNextEventCommon + 665
16 HIToolbox 0x7ff82129b531 _BlockUntilNextEventMatchingListInModeWithFilter + 66
17 AppKit 0x7ff819a6d7b9 _DPSNextEvent + 880
18 AppKit 0x7ff81a365f64 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1304
19 AppKit 0x7ff819a5ed32 -[NSApplication run] + 603
20 Chromium Embedded Framework 0x124c943bc base::mac::CxxPersonalityRoutine(int, _Unwind_Action, unsigned long long, _Unwind_Exception*, _Unwind_Context*) + 4764
21 Chromium Embedded Framework 0x124c931d3 base::mac::CxxPersonalityRoutine(int, _Unwind_Action, unsigned long long, _Unwind_Exception*, _Unwind_Context*) + 179
22 Chromium Embedded Framework 0x124c523bd uhash_compareUnicodeString_69 + 754989
23 Chromium Embedded Framework 0x124c1e3fd uhash_compareUnicodeString_69 + 542061
24 Chromium Embedded Framework 0x124902d3b __gxx_personality_v0 + 401403
25 Max 0x100865f72 MaxCefEventLoopHandler::runMessageLoop() + 18
26 Max 0x100dbb4bb juce::JUCEApplicationBase::main() + 203
27 Max 0x100dbb3d3 juce::JUCEApplicationBase::main(int, char const**) + 83
28 dyld 0x2019ee386 start + 1942

Thread 1::
0 runtime 0x7ff7ffe83294 0x7ff7ffe7f000 + 17044

Thread 2:: timer
0 ??? 0x7ff8a69a2a78 ???
1 libsystem_kernel.dylib 0x7ff8163e65ce __psynch_cvwait + 10
2 libsystem_pthread.dylib 0x7ff81642379c _pthread_cond_wait + 1260

And here’s the patch
_test_lightcntrl.maxpat (1.4 MB)

Hi David,

Thanks for the report, the example patch and the clear reproduction steps! I can reproduce the crash and it looks like it comes from [number~] sending out its values over the scheduler thread. This means that the values going into [beam.sig] come in on a different thread causing trouble down the line. When I turn off ‘overdrive’ or add a [defer] after the [number~]'s outlet, I don’t run into the issue anymore. Can you give that a try? (See screenshot below)

Screen Shot 2024-01-20 at 19.51.35

I’ll ticket this in our system and look for a fix, since Beam of course shouldn’t crash regardless of the thread the value comes from. But maybe these workarounds are acceptable until we release an update.


hi Hidde,
thanks for that. I’m travelling to the coast and setting up a school workshop space tomorrow, so I’ll try out [defer] when I finish on Monday afternoon. I might even get to try it out with the lights if that works straight away!

1 Like