Crash in latest Max 6.0.5 but works fine in Max 5

    May 29 2012 | 11:04 pm
    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: 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 0x00030084 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 0x00310575 juce::MessageManager::deliverMessage(juce::Message*) + 137 9 com.cycling74.Max 0x0042dafe juce::AppDelegateRedirector::runLoopCallback() + 116 10 0x9123e13f __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15 11 0x9123daf6 __CFRunLoopDoSources0 + 246 12 0x912679c8 __CFRunLoopRun + 1112 13 0x912671dc CFRunLoopRunSpecific + 332 14 0x91267088 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 | 12:34 pm
      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 | 2:01 pm
      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 | 2:22 pm
      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 | 2:40 pm
      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.