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?

Thanks,
David

—————
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

#56679
May 30, 2012 at 5:19am

Hello,

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 ?

#203136
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?

#203137
May 30, 2012 at 1:53pm

Hello,

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.

#203138
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.

#203139
May 30, 2012 at 2:16pm

Hello,

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 ?

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

#203141
May 30, 2012 at 2:32pm

Hello,

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 !

#203142
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.

#203143
May 30, 2012 at 2:52pm

Hello,

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 …

#203144

You must be logged in to reply to this topic.