Going to proper stress test (this one point of failure) by running some constant audio playback through it and then turning it on/off automatically every 400ms, and leaving it alone for an hour or whatever and seeing if it crashes again.
1 Like
if you get it to crash like this, then I can do the same in Max 7 
1 Like
Ok, almost 2h of stress test (turning it on/off at different speeds too, in case that did something) and no crashes.
edit:
I spoke too soon…
Not long after it hung indefinitely (and sadly produced no crash report after I force-quit it after 10min of waiting).
arghhhhh - I’m sure @a.harker will know where to look for a hidden crash report
You can try the console or if you can reproduce then use instruments to get a stack trace.
Didn’t see anything in console, or wherever the ~/Library/logs folder is (don’t remember the exact path, but it’s where all the other crash reports have ended up).
Tomorrow I’m doing some more stress testing but on my laptop, as there could have been other stuff going on on my desktop.
Doing some testing on my laptop today and although I haven’t gotten a crash crash, I have gotten massive (>90%) spikes, which since my laptop is faster, is probably what’s crushing my desktop.
I’m going through and minimizing CPU usage in more places, removing the 4x upsampling on my wavefolders etc…, and it seems to spike when lots of things are happening, in the hope that even if it spikes, it stays within a reasonable range.
I’ve not really used Instruments before, but is it just a matter of opening up (a “Blank”?) trace, then start it recording, starting Max, then stopping recording as soon as I get some kind of hiccup?
edit:
I setup a quick test sans entire setup, with “Activity Monitor” and “Leaks”. Is this in the right ballpark of what I should be doing?
Ok, some promising results.
I refactored some stuff and so far no crashes or spikes.
I had a 4x upsampled poly, inside another poly (for muting purposes) inside an M4L device, which itself was inside another poly (for muting purposes) with @steal 1 and only a single voice.
So maybe something inside that poly/shit sandwich was spiking the shit out of the CPU if/when it got loaded/suspended/@stolen midway through its processes.
2 Likes
If you need to save CPU - run in low res mode for the gig. The difference is fans on/off for me.
2 Likes
I’ll try that out now too. I didn’t realize that was still an option in Mojave+.
(lol, holy aliased fonts!! this must be what needing glasses and not wearing glasses feels like…)
1 Like
yeah its pretty awful but retina draws 4x as many pixels so it saves your CPU from having to do all that work as I believe Max is not hardware accelerated
The b(/s)ad news is that this had no impact.
Still getting hangs, and even worse I’m now in Manchester and can’t fully/properly test the patch until Thursday.
I’ll try to do some stress testing in the hotel tomorrow or something, but I obviously can’t set everything up.
I’ve also made a super nuclear version of the patch that disables even more shit, and bypasses a ton of other stuff, including going to @blocking 1 for all my buffer-based stuff, and removing fluid.ampslice~ and other stuff. Also de-M4L-ed the main effect modules in case that has something to do with it.
And also made a thread on the c74 forum asking about Instruments:
Oh, @tremblap’s suggestion of Max7 doesn’t work either. Max crashes instantly when I try to load up all my corpora (polybuffer~s and entrymatchers). I didn’t test that much further since that was enough for me to abandon the hope that Max7 would work fine.
There’s also a Max8 update which I’ve downloaded and am tempted to update on the off chance that it improves things, but there’s only so many dice one man can roll.
Thanks to great poking by @weefuzzy and @a.harker the crash has been solved!
The problem was here:
I figured that would be weird, hence my deferlow off to the left, but I guess setsize is fully asynchronous and this was crashing shit every now and again.
Something I didn’t know, but @weefuzzy also mentioned that getattr @listening 1 is the only way to know when the process is finished. So the fixed/updated code now looks like this:
I’m going to go through and fully tweak the lockout so the onset-based locking out doesn’t reset until the whole fluid.buf... tree has finished. (just need to figure out a signal-based onebang replacement for the lockout)
Interestingly I did get a crash crash in my first test, which pointed to a M4L-related bypass on/off thing earlier, but in running the patch with the updated code it looks fine, so will test the full/normal version of the patch tomorrow.
This is the crashed thread from the crash from today (to be thorough):
Thread 26 Crashed:
0 libsystem_kernel.dylib 0x00007fff6847d2c6 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff68538bf1 pthread_kill + 284
2 libsystem_c.dylib 0x00007fff683e7745 __abort + 144
3 libsystem_c.dylib 0x00007fff683e76b5 abort + 142
4 libsystem_malloc.dylib 0x00007fff684f6077 malloc_vreport + 545
5 libsystem_malloc.dylib 0x00007fff684f5e38 malloc_report + 151
6 libsystem_malloc.dylib 0x00007fff684f29b6 realloc + 313
7 com.cycling74.Max 0x000000010cf47055 void juce::HeapBlock<juce::Rectangle, false>::realloc(unsigned long, unsigned long) + 29
8 com.cycling74.Max 0x000000010cf4701d juce::ArrayBase<juce::Rectangle, juce::DummyCriticalSection>::setAllocatedSize(int) + 37
9 com.cycling74.Max 0x000000010cf46fd0 juce::ArrayBase<juce::Rectangle, juce::DummyCriticalSection>::add(juce::Rectangle const&) + 48
10 com.cycling74.Max 0x000000010cfdbe0d juce::RectangleList::add(juce::Rectangle) + 381
11 com.cycling74.Max 0x000000010d5ca356 juce::NSViewComponentPeer::repaint(juce::Rectangle const&) + 902
12 com.cycling74.Max 0x000000010d54a6b8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 712
13 com.cycling74.Max 0x000000010d54a4e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
14 com.cycling74.Max 0x000000010d54a4e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
15 com.cycling74.Max 0x000000010d54a4e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
16 com.cycling74.Max 0x000000010d54a4e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
17 com.cycling74.Max 0x000000010d54a4e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
18 com.cycling74.Max 0x000000010d54a4e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
19 com.cycling74.Max 0x000000010d54a4e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
20 com.cycling74.Max 0x000000010d54a4e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
21 com.cycling74.Max 0x000000010d54a4e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
22 com.cycling74.Max 0x000000010d54a4e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
23 com.cycling74.Max 0x000000010d54a4e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
24 com.cycling74.Max 0x000000010d54a4e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
25 com.cycling74.Max 0x000000010d54a4e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
26 com.cycling74.Max 0x000000010d54a4e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
27 com.cycling74.Max 0x000000010d54a4e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
28 com.cycling74.Max 0x000000010d54a4e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
29 com.cycling74.Max 0x000000010d54a4e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
30 com.cycling74.Max 0x000000010ce1a729 svgcolor_int(_svgcolor*, long) + 47
31 com.cycling74.Max 0x000000010cdac592 typedmess_fun + 418
32 com.cycling74.Max 0x000000010ce9685b object_method_typedfun + 133
33 max~ 0x000000011ed18bbd plugintoolbar_setbypass + 71
34 com.cycling74.Max 0x000000010ce9742c object_attr_setvalueof + 174
35 com.cycling74.Max 0x000000010cdac4c8 typedmess_fun + 216
36 com.cycling74.Max 0x000000010ce3e7b9 outlet_anything + 627
37 com.cycling74.Max 0x000000010cdac4c8 typedmess_fun + 216
38 com.cycling74.Max 0x000000010cdac4c8 typedmess_fun + 216
39 com.cycling74.Max 0x000000010ce3e7b9 outlet_anything + 627
40 com.cycling74.Max 0x000000010cdac4c8 typedmess_fun + 216
41 com.cycling74.Max 0x000000010cdad15b aeval + 1427
42 com.cycling74.Max 0x000000010cd7f940 atombuf_eval + 132
43 message 0x000000012170a863 jmessage_atombuf_eval + 316
44 message 0x0000000121708b47 jmessage_int + 101
45 com.cycling74.Max 0x000000010ce3d616 outlet_int + 671
46 com.cycling74.Max 0x000000010cdcdc1d change_int + 42
47 com.cycling74.Max 0x000000010ce3d6f2 outlet_int + 891
48 com.cycling74.Max 0x000000010ce3db5b outlet_float + 673
49 com.cycling74.Max 0x000000010ce3db5b outlet_float + 673
50 com.cycling74.Max 0x000000010ce329af linklist_funall_imp + 111
51 com.cycling74.Max 0x000000010ce176cf through_scheduler_sendit_extended + 148
52 com.cycling74.Max 0x000000010ce17921 through_scheduler_float + 98
53 com.cycling74.Max 0x000000010ce3db5b outlet_float + 673
54 scale 0x0000000125149612 scale_float + 85
55 com.cycling74.Max 0x000000010ce3d6f2 outlet_int + 891
56 com.cycling74.Max 0x000000010ce3d246 outlet_bang + 1068
57 com.cycling74.Max 0x000000010ce3d246 outlet_bang + 1068
58 metro 0x000000012508f9f2 metro_out + 89
59 metro 0x000000012508fa1e metro_tick + 33
60 com.cycling74.Max 0x000000010d0610e7 time_tick + 49
61 com.cycling74.Max 0x000000010cd82e86 clock_execute + 56
62 com.cycling74.Max 0x000000010cdbf287 sched_takepoll + 637
63 com.cycling74.Max 0x000000010ce43b9c mactimer_isr + 192
64 com.cycling74.Max 0x000000010ce418f8 systhread_threadproc + 64
65 libsystem_pthread.dylib 0x00007fff685362eb _pthread_body + 126
66 libsystem_pthread.dylib 0x00007fff68539249 _pthread_start + 66
67 libsystem_pthread.dylib 0x00007fff6853540d thread_start + 13
crash3.zip (36.7 KB)
1 Like
@a.harker might have something more elegant, but IME this has been the only reliable way to avoid deadlocks from resizing buffers you then need to access straight away.
I’m having to do this same dance a lot before bufcomposing at the moment, which makes me think we should add a ‘destructive’ flag or something, to save this (error prone) step
1 Like
Yeah that would be handy, as it’s a risky thing (as it turns out) and real easy to overlook.
(as an aside, is it me, or is it tricky to build a signal-rate onebang replacement without some silly tapin~/tapout~ recursion?)
Also, why resizing to 0 samps? This is again prone to freak some native objects as dicussed above. samps 1 1 is my favourite now that @weefuzzy showed me this trick many months ago…
1 Like
Does this work?
----------begin_max5_patcher----------
1156.3ocwYs0iapCD9YxuhHds6oxFBWRk1GN+NpNJx.ND2RrQfYa1V0829wW
3dfDmcCYegnLC1y7MeyL1X+mUV1QrS3R60ea82WaY8mUVVJQRAV0+2x9H5Tb
FpT8Z1T7uXQ+v9IsJN9DWINNiD+y2ZDmi3wGHzzcE3Xtd1ggteE7zZHHP9i6
V4SGmuBV+e0igVcjUwyvbkcf0R0h3uli0SicIIkhxraGFIQYegO8ON.6t4hP
amJor+tZk7wSFhxxXVN9Rvw0CnPfquBUtf1elAPfy8W31I8Wm2g+9dYkMNZV
A5rXrBL7twJQUbNidI3.Uzgula1z77VQSDhlNMVB5LdA5HliK1gonnLbeJd4
wIbqho77VJb58Pv4LYs4W.4NdJjCCUsQfNvkHi0c55x9dEtnFW0.yxdOIC+B
tnjHXtNCaYixy6I1p2PjQievTST3SshHTsHXqnB7KjlwCZkhJDwFtHvTUnvj
8I+M1cSCKAWPqHsTihWpcIECPE7ZYNJVOXIQ0ntKZGtQGkUwb+MpxpMg8ZxI
X3zLV7OwI8cNaQySJglWfKwTNhOx2sSv6QUY7c6YTdI42JOP0AZB86q8vIUJ
wfx8+2BhfLadkzBRBiJchALgTbi4D0PphG4yNvndCJJehAKRLDgkYTVJ.YUY
DpPRT0UINMJ4LV1PUsiKCumWqNmPoihhbV97JKHoGtvXiXBkGuzbqzTtqhp0
tSjSv2UhdYXzlixxpKSGN8mPTxQDGyIZJvAzpT2o3PYbAKKa.d0ZdYBMIhb7
X7uHI7CJC0OYP75j7ljH6VVNgjhK4CkwQokCkTxeUGz6IpJptFdGGeLOSfhg
uvfME0ufseCsAxuTisgM2d942VC6qYhlbA5cS3n5woq552ha91bF0pab6t.6
gS6nchX0zWutGx8OjDePrNT6tstRPA.5sx2xET7mMn.eLAkDbF5UQpxUSVp2
Qsidmb9aV3.ylO6rkTQ450xUp2bdf2z6p8NGRb+rCIxdJ.yRSfa8dHMUb9ri
Ie442LLh3qJbbW5HB7gDQTypQcR0o.tsOWJXClE2fdJhYGOJ1q3f0gUyDMAe
5d210jfDDF9HiRv6ST5dlJowfQcZc8BLNLAlIBLeGC3GMOoaC9YD5b6rSANo
9oCMkrph3F1rtC25g3TrSUNg194NeucAS46YDwbq9.zPevYA8gMF5CtKnO3a
nODrf9Pfg9v4bFqHQebBfOUGSRPvocL3xj8BLzy7WxRH3MvavExIbM0GluPt
VXyg7XK+R9jc5SsXGhyKHQUbcuu9mZ0M800oYrHTV82N2d1KS7w2q5bta7HA
6uz7jm6t9ihclYYYSO8uIO2uoON9lS6bhUd5V0A7Nf5f0WuvYc5D5aDXm3FF
l4n2WJDcMxyIX6hQdd2GxSM0C2lfF4iKoqw+48SB6WKOWcraWyjyhwlZIGfo
VB7Asj75.tpkZbmOlkbMASaG7RCW978a5.SLc3c.jdOJda6iJUzHZKbZVCdV
02naLQZzQ2TxnaI47aHY9aGY7MinVvbtaDY0eW8+.w1unu.
-----------end_max5_patcher-----------
1 Like
Did I say that? Can’t remember why 
0 channels is definitely taboo, but 0 samples should be ok.
I think no resizing at all would be the best. Rod, what don’t you have one large buffer, with 1 variable (many ways to do that, for instance [v]) which is the valid end point? that way you never resize, which is my favourite best practice for Max buffer in RT settings (since I had so many problems with them over the years)