Max and live stuck when saving a device
I have to force quit both apps. This happens since I upgraded to version 9.7 and Max 7.3
Any similar cases ?
MBP 2,3 ghz I7 16Go SSD+HD 10.8.5
Sometimes it happens for me too, especially with a device that contains [live.step].
yupp i see that too. since longer than Live 9/Max 7 already. but i couldn't reliably reproduce up to now. recently my suspicion goes to the Live parameter system (especially when pattr system is involved). There seem to be cases where Max updates the Live parameters while saving...
Please give Max 7.3.1 a whirl, as these problems might be fixed with this release:
https://cycling74.com/forums/max-7-3-1-hotfix-released/
Let us know if you are still having problems.
-Ben
I've just seen it and going to try. That happened to me even with the simplest patches containing just a few objects.
@BEN BRAKEN:
In my case it's still happening (with Max 7.3.1). Live crashes (and max freezes) occasionally when saving a device. The crash log looks like this:
Common in all crashes is the line: WiresPrivate::mfl_device_blob_changed(WiresPrivate::_mfl_device*, symbol*, long, atom*, atom*)
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.ableton.live 0x0000000101c723c8 0x100000000 + 29828040
1 com.ableton.live 0x0000000101c92977 0x100000000 + 29960567
2 com.cycling74.patcher 0x000000011b74f91d WiresPrivate::mfl_device_blob_changed(WiresPrivate::_mfl_device*, symbol*, long, atom*, atom*) + 142
3 com.cycling74.MaxPlugLib 0x00000001250d5ff4 object_method_imp + 352
4 com.cycling74.MaxPlugLib 0x0000000125210c2e param_hub_blobchanged_qfn + 77
5 com.cycling74.MaxPlugLib 0x00000001250b6eb0 sched_dequeue + 198
6 com.cycling74.MaxPlugLib 0x00000001251e0d95 MainThreadEventHandler::invoke() + 101
7 com.cycling74.MaxPlugLib 0x000000012532a290 juce::InternalTimerThread::callTimers() + 176
8 com.cycling74.MaxPlugLib 0x0000000125329289 juce::MessageManager::deliverMessage(juce::Message*) + 55
9 com.cycling74.MaxPlugLib 0x000000012540e20f juce::AppDelegateRedirector::runLoopCallback() + 99
10 com.apple.CoreFoundation 0x00007fff8c266881 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
11 com.apple.CoreFoundation 0x00007fff8c245fbc __CFRunLoopDoSources0 + 556
12 com.apple.CoreFoundation 0x00007fff8c2454df __CFRunLoopRun + 927
13 com.apple.CoreFoundation 0x00007fff8c244ed8 CFRunLoopRunSpecific + 296
14 com.apple.HIToolbox 0x00007fff8bcf4935 RunCurrentEventLoopInMode + 235
15 com.apple.HIToolbox 0x00007fff8bcf476f ReceiveNextEventCommon + 432
16 com.apple.HIToolbox 0x00007fff8bcf45af _BlockUntilNextEventMatchingListInModeWithFilter + 71
17 com.apple.AppKit 0x00007fffa06e8df6 _DPSNextEvent + 1067
18 com.apple.AppKit 0x00007fffa06e8226 -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 454
19 com.apple.AppKit 0x00007fffa06dcd80 -[NSApplication run] + 682
20 com.ableton.live 0x0000000100bd438b 0x100000000 + 12403595
21 com.ableton.live 0x00000001002bb709 0x100000000 + 2864905
22 com.ableton.live 0x0000000100001934 0x100000000 + 6452
And the crashes disappear when I remove my pattrhub/autopattr/preset combination.
The patch has some (4) bpathers containing live.ui object and autopattr all loading the same patch. This mean that the Long Names/Parameter Names names are identical and automatically index (parameterName[1]) by Max/Live. Could that be the reason?
I also observed two curious things:
* Sometimes after opening the device the autopattr object appears in the pattshub-storage window, sometimes not.
* Sometime the indentation of the parameters inside the bpatchers disappear in the storage window - all parameters show on top level.
@JAN, could you drop a note to support with an example patch? Also, is this the same crash as before? There were some changes to blob parameters for Max 7.3.1. Hopefully it is a quick fix!
-Ben
Anecdotally, this looks like something different than the memory leak which was fixed for Max 7.3.1. This looks more like a bug we recently spent some time on which was reliably triggered by laying on the Save keyboard shortcut. We're still working with Ableton on a resolution for that, but it is on our radar.
In any case, if you have an example device to send to support, that would be great.
@Jeremy @Ben : I'll send you something later today. I'll try to narrow it down before. Hopefully I will find sequence of steps that can reliably reproduce the issue. Right now it is quite unpredictable. I have some suspects that may be involved (e.g. combination of preset recalling/interpolating, having changed a parameter in the inspector plus Cmd+S).
Indeed it occurred before and after 7.3.1
It seems Max tries to save the device as a project (I accidentally found a zero ko project folder named like my device) when you try to save it. Is that normal behavior ? Then Max is stuck with the beachball and I have to force quit.
Same happens to me sometimes when I save a m4l device. Fortunately the crash happens after saving. So I never lose progress but have to restart Live + M4L often after saving. But I can say it also happens with devices without pattr or preset or live.step.
btw: on win 7
The device is saved in the selected destination, but it's a "huge" 7.7 Mo considering it just contains a plugsync~object and a few number boxes... I can't open it again.
Please put the corrupt device on Dropbox or something and send a link to support, please.
Jeremy : done. Mentioned this thread...
Same with 7.3.1 here.
I've worked on a new device and Max seems to totally dislike the save command... Both apps crashed again, and but the device seems to be saved again with a "huge" filesize of 8 Mo... If I reload it and hit the edit button, max crashes. It seems really serious : I can't edit and save devices anymore. Please help !
It seems temperamental. Once I could rebuild the same simple device using [plugsync~] that had got corrupted in another attempt and I could save it regularly, re-open it, and its size is a normal 12 ko. But then I tried to construct another device based on the Four LFO patch by G. Taylor and Max crashed when saving, but I could find the saved corrupted device which is again more than 8 Mo...
Jeremy, any news ? I've got other corrupted files weighing almost the same size (from 5 to 8 Mo for very simple devices) of various failed attempts. I'm in the process of reinstalling Max and Live. First time such mess happens for me...
Sorry, I've been out sick the last couple of days. I'll take a look at the device this afternoon.
News boyz and girlz : Jeremy is investigating about a weird bug that has created about 12000 snapshots in my document folder and led to try to write them with each new device, hence the file size increase. According to C74, this is due to "poor design decision", they're working a a fix and probably a "rich design decision". After re-installing Max and Live everything seems back to normal.
Well, the "poor design decision" language wasn't an official statement, just my opinion about how the design causes what happens in this pathological case. In any case, the situation which led to the propagation of thousands of snapshots has been fixed and will be in a future update.
Yeah, excuse me Jeremy for this lack of accuracy. Such a pathological case indeed ! First time I was stuck like this since I started with Max. Do you mean that it could happen again while waiting for the upd ?
Same here.
I was wondering if the udp receive and send objects are the guilty ones. Do you guys use theses?
The crash doesn't seem to happen when there's no such objects in the patch.
No udp objects involved here.
Hello,
Still the exact same here with 8.5.2 and LIve 11210b3.
Almost eachtime when I save my (big device) device, Max and Live freeze and/or crach.
It seems too to happen more often when it's saved with shortcuts..
It happens 20 times a day !
As 11olsen said 6 years ago, almost each time the work is well saved but I have to reopen Max/Live...It's a very long time of loading with this buig patch/live.set
The issue seems to be linked with pattrstorage handle.
But I am not sure. It's very hard to debug....
Other people still notice this problem ?