Crash in latest Max 6.0.5 but works fine in Max 5
While it appears that the scheduling issues I encountered in earlier versions of Max 6 are solved in 6.0.5, I’ve run into a new problem. It’s clearly timing related because I can’t control exactly WHEN it will happen but I can pretty confidently make it happen in reasonably short order by sending a lot of OSC data from my Eigenharp Alpha into Max 6 (I don’t believe the problem is with the OSC stuff though).
While Max 5 behaves perfectly fine, Max 6 will crash within 5 to 15 seconds of my just sliding my hand over multiple keys of the eigenharp.
I’m wondering if someone can tell from the stack trace what might be going on. For example, what object might jbox_updatetextfield_safe be referring to?
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.cycling74.Max 0x0000d5a4 atombuf_totext_flags + 322
1 com.cycling74.Max 0x001250a5 jbox_updatetextfield_safe + 159
2 com.cycling74.MaxAPI 0x02af7a9d jbox_updatetextfield_safe + 45
3 com.cycling74.message 0x0e7e6565 jmessage_qfn + 25
4 com.cycling74.Max 0×00030084 sched_dequeue + 256
5 com.cycling74.Max 0x00017cb4 max_tick + 81
6 com.cycling74.Max 0x00311bd7 juce::InternalTimerThread::callTimers() + 133
7 com.cycling74.Max 0x0031197e non-virtual thunk to juce::InternalTimerThread::handleMessage(juce::Message const&) + 20
8 com.cycling74.Max 0×00310575 juce::MessageManager::deliverMessage(juce::Message*) + 137
9 com.cycling74.Max 0x0042dafe juce::AppDelegateRedirector::runLoopCallback() + 116
10 com.apple.CoreFoundation 0x9123e13f __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
11 com.apple.CoreFoundation 0x9123daf6 __CFRunLoopDoSources0 + 246
12 com.apple.CoreFoundation 0x912679c8 __CFRunLoopRun + 1112
13 com.apple.CoreFoundation 0x912671dc CFRunLoopRunSpecific + 332
14 com.apple.CoreFoundation 0×91267088 CFRunLoopRunInMode + 120
15 com.apple.HIToolbox 0x98c29723 RunCurrentEventLoopInMode + 318
16 com.apple.HIToolbox 0x98c30a8b ReceiveNextEventCommon + 381
17 com.apple.HIToolbox 0x98c308fa BlockUntilNextEventMatchingListInMode + 88
18 com.apple.AppKit 0x9a9850d8 _DPSNextEvent + 678
19 com.apple.AppKit 0x9a984942 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 113
20 com.apple.AppKit 0x9a980cb1 -[NSApplication run] + 911
21 com.cycling74.Max 0x004189c7 juce::MessageManager::runDispatchLoop() + 731
22 com.cycling74.Max 0x002a8896 juce::JUCEApplication::main(juce::StringArray const&) + 68
23 com.cycling74.Max 0x002a89b9 juce::JUCEApplication::main(int, char const**) + 73
24 com.cycling74.Max 0x0000ad0b _start + 209
25 com.cycling74.Max 0x0000ac39 start + 41
Well, that’s a good question (and the support team queried this as well). The problem is that my ‘patch’ contains many sub patchers and abstractions and this use of a message box is not something I tend to use other than accidentally. So it’s going to be a headache to find it.
Anyone know of good tools for finding particularly configured objects in a nested folder?
If I knew which .maxpat file to open, this would not be an issue. The problem is that my system is made up of (at this point) hundreds of abstractions and other patchers so it’s almost literally looking for a needle in a haystack.
I could do a recursive grep but the problem there is that I would get every single ‘message’ object in my environment.
So I really need a better mechanism for searching that recognizes connections as well.
Speaking of better mechanisms, what I would kill for is a visual "diff" so that I can compare different versions of max objects that are checked into my version control system.
All the ‘diff’ systems for comparing different versions of a file are text based. But it’s almost impossible to use them with max patchers because, when you make even a minor change, the objects get reordered in the file and so the textual changes look huge to a diff tool.
So it would be extremely useful to have a tool that can visually display two versions of a patcher, highlighting the areas that are different. Non-trivial but probably a very interesting project (any grad students out there looking for a project?)
Yeah, I shouldn’t have mentioned ‘diff’ — that’s a red herring in terms of my problem. I don’t know how Shark would help me — we already believe it’s a messagebox (an object supplied by Cycling74) that’s causing the issue — the question is finding WHICH message box in a large number of patchers and abstractions is responsible.