Crash in latest Max 6.0.5 but works fine in Max 5

May 29, 2012 at 11:04pm

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:
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
11 0x9123daf6 __CFRunLoopDoSources0 + 246
12 0x912679c8 __CFRunLoopRun + 1112
13 0x912671dc CFRunLoopRunSpecific + 332
14 0×91267088 CFRunLoopRunInMode + 120
15 0x98c29723 RunCurrentEventLoopInMode + 318
16 0x98c30a8b ReceiveNextEventCommon + 381
17 0x98c308fa BlockUntilNextEventMatchingListInMode + 88
18 0x9a9850d8 _DPSNextEvent + 678
19 0x9a984942 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 113
20 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

May 30, 2012 at 5:19am


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

AFAIK “jbox” refer to an UI object method ; so is there any “message box” connect to an UI object with text drawn in your patch ?

May 30, 2012 at 12:34pm

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?

May 30, 2012 at 1:53pm


Open the .maxpat file with any text editor (i use Xcode for that) and search "maxclass" : "message"or any class you want to find ; AFAIK it’s not possible to search all UI object with a unique keyword.

May 30, 2012 at 2:01pm

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.

May 30, 2012 at 2:16pm


oops ; I have no idea at all about the “diff” method …

… use a profiler like “Shark” focused on ‘jbox_updatetextfield_safe’ function to find any clues about the identity of the object ?

May 30, 2012 at 2:22pm

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?)

May 30, 2012 at 2:32pm


i see ; interesting job to do for a student ;-)

but in your case the crash occurs due to an external and that is an opaque box anyway !

May 30, 2012 at 2:40pm

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.

May 30, 2012 at 2:52pm


Are you sure it is a message box ?
As all those functions before the crash are private … is your info comes from the cycling74 dev ?

I was speaking about “Shark” to find the object/class that crashed ; but if you are already 100% sure that is a message box ; in that case yes it will be hard to find the buggy one without a long trial and error process ; the brute force should to replace all of them with [prepend]/[append]/[trigger] until it does not crash …

This is a reason why i really hate closed sources …


You must be logged in to reply to this topic.