Max Crashed after Update but crash report pointing to flu coma

Bruxizme · October 6, 2023, 3:23pm

Hi!

I’m using Flucoma (within Max) for an installation project.

I have been doing tests (leaving the patch running for days) for almost the whole month of September and haven’t had any crashes until last Monday that I updated to the latest Max version.

Max now crashes every now and then and it’s referencing FluCoMA’s KDTree object on the crash report.

I also contacted Cycling 74 as it only happened when updated to the newest version.

Translated Report (Full Report Below)

Process: Max [3642]
Path: /Applications/Max.app/Contents/MacOS/Max
Identifier: com.cycling74.Max
Version: 8.5.6 (13186257284) (8.5.6)
Code Type: ARM-64 (Native)
Parent Process: launchd [1]
User ID: 501

Date/Time: 2023-10-05 22:38:47.7371 +0100
OS Version: macOS 13.4 (22F2063)
Report Version: 12
Anonymous UUID: 397C0C0F-FFBE-CB33-2D29-5E8B1A26E856

Time Awake Since Boot: 210000 seconds

System Integrity Protection: enabled

Crashed Thread: 0 CrBrowserMain Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Codes: 0x0000000000000001, 0x0000000000000000

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

VM Region Info: 0 is not in any region. Bytes before following region: 4344807424
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
—>
__TEXT 102f88000-103cec000 [ 13.4M] r-x/r-x SM=COW …nts/MacOS/Max

Thread 0 Crashed:: CrBrowserMain 0 fluid.libmanipulation 1 fluid.libmanipulation 2 fluid.libmanipulation 3 fluid.libmanipulation 4 fluid.libmanipulation 5 fluid.libmanipulation 6 fluid.libmanipulation 7 fluid.libmanipulation 8 fluid.libmanipulation 9 Max 10 Max 11 Max 12 Max 13 message 14 Max 15 Max 16 fluid.list2buf 17 Max 18 Max 19 Max 20 Max 21 Max 22 Max 23 CoreFoundation 24 CoreFoundation 25 CoreFoundation 26 CoreFoundation 27 CoreFoundation 28 HIToolbox 29 HIToolbox 30 HIToolbox 31 AppKit 32 AppKit 33 AppKit 34 Chromium Embedded Framework 35 Chromium Embedded Framework 36 Chromium Embedded Framework 37 Chromium Embedded Framework 38 Chromium Embedded Framework 39 Max 40 Max 41 Max 42 dyld Dispatch queue: com.apple.main-thread
0x3aea87bf0 fluid::algorithm::KDTree::kNearest(fluid::algorithm::KDTree::Node const*, fluid::FluidTensorView<double const, 1ul>, std::__1::vector<std::__1::pair<double, fluid::algorithm::KDTree::Node const*>, foonathan::memory::std_allocator<std::__1::pair<double, fluid::algorithm::KDTree::Node const*>, fluid::FallbackAllocator>>&, long, double, long) const + 88
0x3aea87cf8 fluid::algorithm::KDTree::kNearest(fluid::algorithm::KDTree::Node const*, fluid::FluidTensorView<double const, 1ul>, std::__1::vector<std::__1::pair<double, fluid::algorithm::KDTree::Node const*>, foonathan::memory::std_allocator<std::__1::pair<double, fluid::algorithm::KDTree::Node const*>, fluid::FallbackAllocator>>&, long, double, long) const + 352
0x3aea87d48 fluid::algorithm::KDTree::kNearest(fluid::algorithm::KDTree::Node const*, fluid::FluidTensorView<double const, 1ul>, std::__1::vector<std::__1::pair<double, fluid::algorithm::KDTree::Node const*>, foonathan::memory::std_allocator<std::__1::pair<double, fluid::algorithm::KDTree::Node const*>, fluid::FallbackAllocator>>&, long, double, long) const + 432
0x3aea87cf8 fluid::algorithm::KDTree::kNearest(fluid::algorithm::KDTree::Node const*, fluid::FluidTensorView<double const, 1ul>, std::__1::vector<std::__1::pair<double, fluid::algorithm::KDTree::Node const*>, foonathan::memory::std_allocator<std::__1::pair<double, fluid::algorithm::KDTree::Node const*>, fluid::FallbackAllocator>>&, long, double, long) const + 352
0x3aea87d48 fluid::algorithm::KDTree::kNearest(fluid::algorithm::KDTree::Node const*, fluid::FluidTensorView<double const, 1ul>, std::__1::vector<std::__1::pair<double, fluid::algorithm::KDTree::Node const*>, foonathan::memory::std_allocator<std::__1::pair<double, fluid::algorithm::KDTree::Node const*>, fluid::FallbackAllocator>>&, long, double, long) const + 432
0x3aea8786c fluid::algorithm::KDTree::kNearest(fluid::FluidTensorView<double const, 1ul>, long, double, fluid::FallbackAllocator&) const + 216
0x3aea84dc4 fluid::client::kdtree::KDTreeClient::kNearest(std::__1::shared_ptr<fluid::client::BufferAdaptor const>, tl::optional) const + 480
0x3aea96bc8 decltype(auto) fluid::client::NRTSharedInstanceAdaptorfluid::client::kdtree::KDTreeClient::invoke<1ul, fluid::client::NRTSharedInstanceAdaptorfluid::client::kdtree::KDTreeClient, std::__1::shared_ptr<fluid::client::BufferAdaptor const>&, tl::optional&>(fluid::client::NRTSharedInstanceAdaptorfluid::client::kdtree::KDTreeClient&, std::__1::shared_ptr<fluid::client::BufferAdaptor const>&, tl::optional&) + 176
0x3aea964cc void fluid::client::FluidMaxWrapper<fluid::client::NRTThreadingAdaptor<fluid::client::NRTSharedInstanceAdaptorfluid::client::kdtree::KDTreeClient>>::invokeMessageImpl<1ul, 0ul, 1ul>(fluid::client::FluidMaxWrapper<fluid::client::NRTThreadingAdaptor<fluid::client::NRTSharedInstanceAdaptorfluid::client::kdtree::KDTreeClient>>, symbol, long, atom*, std::__1::integer_sequence<unsigned long, 0ul, 1ul>) + 408
0x1032dbecc typedmess_fun + 400
0x1032c7bd0 outlet_anything + 1296
0x1032dbecc typedmess_fun + 400
0x1032a98e4 aeval + 1708
0x124c654c8 jmessage_atombuf_eval + 348
0x1032dbecc typedmess_fun + 400
0x1032c7bd0 outlet_anything + 1296
0x2e70350b0 fluid::client::buffertolist::FluidListToBuf_list(fluid::client::buffertolist::FluidListToBuf*, symbol*, long, atom*) + 912
0x1032db250 outlet_list + 1336
0x103316d5c defer_exec + 100
0x10330bce4 sched_dequeue + 372
0x1030f07e4 MainThreadEventHandler::invoke() + 84
0x103614fd8 juce::TimerThread::callTimers() + 340
0x103615928 juce::MessageQueue::runLoopCallback() + 64
0x19b6fa63c CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 28
0x19b6fa5d0 __CFRunLoopDoSource0 + 176
0x19b6fa340 __CFRunLoopDoSources0 + 244
0x19b6f8f48 __CFRunLoopRun + 828
0x19b6f84b8 CFRunLoopRunSpecific + 612
0x1a4f42c40 RunCurrentEventLoopInMode + 292
0x1a4f42a7c ReceiveNextEventCommon + 648
0x1a4f427d4 _BlockUntilNextEventMatchingListInModeWithFilter + 76
0x19e919d44 _DPSNextEvent + 636
0x19e918ee0 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 716
0x19e90d344 -[NSApplication run] + 464
0x11ce3fe74 base::mac::CxxPersonalityRoutine(int, _Unwind_Action, unsigned long long, _Unwind_Exception*, _Unwind_Context*) + 4672
0x11ce3ecf0 base::mac::CxxPersonalityRoutine(int, _Unwind_Action, unsigned long long, _Unwind_Exception*, _Unwind_Context*) + 188
0x11ce01b74 cef_time_delta + 2635552
0x11cdd5560 cef_time_delta + 2453772
0x11cafa194 __gxx_personality_v0 + 374708
0x103119f80 MaxCefEventLoopHandler::runMessageLoop() + 28
0x103610d04 juce::JUCEApplicationBase::main() + 192
0x103610c24 juce::JUCEApplicationBase::main(int, char const**) + 88
0x19b2c3f28 start + 2236

rodrigo.constanzo · October 6, 2023, 5:28pm

Do you have a patch that can reproduce the issue?

Bruxizme · October 6, 2023, 5:41pm

Rodrigo, Borja here

I unfortunately can’t share the patch… my boss would kill me.

anyway you would need to have it running for several hours before crashing (sometimes even +12) .

Tough one…

jamesbradbury · October 6, 2023, 8:36pm

If we can’t see the specific patch(es) it would be good to understand at least what you are doing in the patch. Looks like the crash was caused at least partially by the fluid.kdtree and from a nearest neighbour search.

Again, if you can’t share the exact patch maybe you can setup some kind of logging to show what messages were coming into the object before it crashed. Otherwise it is very hard to know what is going on. Are you also on the latest version?

Bruxizme · October 6, 2023, 9:47pm

thanks for your reply James,

I understand,

the patch is doing a lot of different stuff (its an AV installation).

but I can explain the parts that use KDTree:

in one of them, what’s coming in is the name of different datasets and the buffer to query.

And in the other(s) (x3) the dataset doesn’t even change.

I must insist, both parts of the patch were done several months ago and have worked seamlessly until now that I upgraded Max to version 8.5.6.

im up to date with FluCoMa as well…

thanks a lot

jamesbradbury · October 6, 2023, 10:01pm

Do you need to fit barras1 before every knearest barras1?

Bruxizme · October 6, 2023, 10:02pm

Barras1 is meant to be changing with every bang…

EDIT: ah but you are right, there’s no reason to fit it every time.

there is a mistake there, sure but anyway it worked before!

jamesbradbury · October 6, 2023, 10:09pm

Right, but it might be unrelated to the version change and only surfaced coincidentally with the version update. I’d say if you can get it to crash after 12 hours again (or sooner hopefully) after this change then we can keep digging but this is very slippery

Bruxizme · October 6, 2023, 10:11pm

Right, I’ll change this and let you know on Monday.

hope it works

thank you.

Bruxizme · October 7, 2023, 12:26pm

Hi,

It did crash after 3 hours or so, with the change that you suggested (sending the fit barrasX message with a loadbang on startup).

rodrigo.constanzo · October 7, 2023, 12:59pm

As @jamesbradbury said, without looking at patches it’s hard to pinpoint, but from experience there may be something weird going on with threading as I see defer and delay both interspersed, which shift between threads.

I would try removing all the defers (and adding @autosize 0 if the defer is only there to remove complaints about that in fluid.list2buf).

Bruxizme · October 11, 2023, 10:02am

i thought defer would only move thread to the messages that are passed onto it. (and not the chain afterwards). these things are so mysterious to me.

…

anyway wanted to let you know that Its now fixed by downgrading to the previous version of Max. (as I expected).

the patch has been running for about 30 hours…

thanks for the help

tremblap · October 12, 2023, 8:01am

that is worrying… @a.harker did you notice any new problem r.e. threading in framelib?

spluta · October 12, 2023, 10:49pm

which version of Max does not have the issue? One of my students is suddenly getting constant crashes.

Bruxizme · October 13, 2023, 7:13am

Previous to the current, 8.5.5

rodrigo.constanzo · October 13, 2023, 8:07am

Perhaps unrelated but after tracking down some pinwheeling/hanging I was getting (with help from @jamesbradbury) we found that dict was misbehaving where it was taking forever to load and eventually fully hanging. A real innocuous dict too.

tremblap · October 13, 2023, 8:42am

the native dict?

tremblap · October 13, 2023, 8:43am

just so we don’t chase ghosts (I have no crashes on Monterey and last version of Max) what are they doing and are they using the package manager version or the nightlies?

rodrigo.constanzo · October 13, 2023, 8:53am

As in dict (the Max object), yeah.

For whatever reason in a patch next to a poly~ it was hanging like crazy.

a.harker · October 13, 2023, 10:15am

I moved to 8.5.6 a couple of months ago for a recording session, because it fixes the line~ issues that have been going on during max 8 changes.

For my purposes (a single patch) I don’t think I saw it crash once, but that was for a specific patch - however it was one making using of some flucoma, quite a bit of framelib and my own other externals. Since then I have not been doing any heavy lifting in Max.

I’d be wary in this thread of conflating possibly different issues about a specific Max version (@spluta seems to be likely to be describing something totally different - possibly related to the student’s patch, or possibly Max install corruption). In all cases of crashes one should aim to isolate and get a reproducible minimal case. There is not even any certainty that threading is the issue here, although for very occasional crashes it is certainly a contender.

We know a few things for sure in the case originally raised:

that kdtree crashed an Apple Silicon Mac running Max 8.5.6 by referencing a null point.
that this happened during a nearest neighbour search
that this happened on the main thread

Other stuff is conjecture. The most helpful next step would be a small patch that crashes reliably within some length of time that is not crazy (even if that is several hours) and then for that patch to be run in the debugger to allow a better inspection of the issue. Ideally that wouldn’t be the full patch anyway - smaller is always better for reproducing bugs.