[function] preset interpolation is crashing Max 9.0.6.0
Wildly interpolating 4 presets of [function] object with nodes object often crashes Max.
See the event log below.
Faulting application name: Max.exe, version: 9.0.6.0, time stamp: 0x681d12e6
Faulting module name: function.mxe64, version: 9.0.6.0, time stamp: 0x681d138c
Exception code: 0xc0000005
Fault offset: 0x0000000000001965
Faulting process id: 0x5038
Faulting application start time: 0x01dbc7d72d78ceed
Faulting application path: C:\Program Files\Cycling '74\Max 9\Max.exe
Faulting module path: C:\Program Files\Cycling '74\Max 9\resources\externals\max\function.mxe64
Report Id: dcc55faf-c50d-4a51-9ce1-22bad2f8a250
Faulting package full name:
Faulting package-relative application ID:
I have also tried to upload the dump file but for some unknown reason the forum does not allow me to. The upload dialog simply disappears and that's it.
I have also tried to zip it but then the error "Editor.uploads.unaccepableFileType" pops up.
This is the dump file content after analysis in WinDbg:
* *Exception Analysis* *********************************************************************************** WARNING: Unable to verify checksum for Max.exe*** WARNING: Unable to verify checksum for MaxAudio.dll*** WARNING: Unable to verify checksum for ad_mme.mxe64KEY_VALUES_STRING: 1Key : AV.DereferenceValue: NullClassPtrKey : AV.FaultValue: ReadKey : Analysis.CPU.mSecValue: 843Key : Analysis.Elapsed.mSecValue: 25435Key : Analysis.IO.Other.MbValue: 26Key : Analysis.IO.Read.MbValue: 0Key : Analysis.IO.Write.MbValue: 52Key : Analysis.Init.CPU.mSecValue: 1108Key : Analysis.Init.Elapsed.mSecValue: 45113Key : Analysis.Memory.CommitPeak.MbValue: 110Key : Failure.BucketValue: NULL_CLASS_PTR_READ_c0000005_function.mxe64!UnknownKey : Failure.HashValue: {a8c56d61-e233-4538-a801-d42461f5ea04}Key : Timeline.Process.Start.DeltaSecValue: 153Key : WER.OS.BranchValue: vb_releaseKey : WER.OS.VersionValue: 10.0.19041.1Key : WER.Process.VersionValue: 9.0.6.0FILE_IN_CAB: Max-2025-05-18_11-30-46-28065a4add0.dmpNTGLOBALFLAG: 0CONTEXT: (.ecxr)rax=0000000000000000 rbx=0000000000000003 rcx=00000000ffffffffrdx=0000000000000001 rsi=0000000000000000 rdi=0000000000000002rip=000000002d521965 rsp=00000000062af200 rbp=000000000710dda0r8=0000000000000000 r9=00000000379dafb8 r10=00000000062af010r11=00000000062af040 r12=000000000000000c r13=0000000000000024r14=000000002c33ca90 r15=0000000000000000iopl=0 nv up ei pl nz na pe nccs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202function!ext_main+0x855:00000000`2d521965 f20f104828 movsd xmm1,mmword ptr [rax+28h] ds:00000000`00000028=????????????????Resetting default scopeEXCEPTION_RECORD: (.exr -1)ExceptionAddress: 000000002d521965 (function!ext_main+0x0000000000000855)ExceptionCode: c0000005 (Access violation)ExceptionFlags: 00000000NumberParameters: 2Parameter[0]: 0000000000000000Parameter[1]: 0000000000000028Attempt to read from address 0000000000000028PROCESS_NAME: Max.exeREAD_ADDRESS: 0000000000000028ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.EXCEPTION_CODE_STR: c0000005EXCEPTION_PARAMETER1: 0000000000000000EXCEPTION_PARAMETER2: 0000000000000028STACK_TEXT:00000000`062af200 00000001`404aa3a0 : 00000000`00000001 00000000`00000000 00000000`38126700 00000000`00000001 : function!ext_main+0x85500000000`062af290 00000001`404aa3a0 : 00000000`38128b60 00000000`00000000 00000000`38b42080 00000000`00000000 : Max!readtohandle+0x103000000000`062af300 00007ff8`0f3e1d43 : 00000000`3b36d920 00000000`00000095 00000000`00000001 00000000`00000001 : Max!readtohandle+0x103000000000`062af370 00000001`404b1be1 : 00000000`2cfae3f0 00000000`00000095 00000000`00000001 00000000`00000001 : MaxAudio!schedvalue_set+0x9300000000`062af3b0 00007ff8`0f3df9fa : 00000000`00000001 00000000`00000010 00000000`3aae3d70 00000000`00000000 : Max!scheduler_run+0x1a100000000`062af410 00007ff8`0f3debbb : 00000000`2cfae3f0 00000000`00000000 00000000`3aae3d70 00000000`00000000 : MaxAudio!plugrunner_serviceclocks+0x2a00000000`062af480 00007ff8`0f3d5ea6 : 00000000`2cfae3f0 00000000`00000001 4102a6aa`b768a000 00000000`3b6c2ca0 : MaxAudio!plugrunner_process+0x39b00000000`062af510 00007ff8`0f3d08c7 : 00000000`3b6c2ca0 00000000`00000000 00000000`00000010 00000000`00000010 : MaxAudio!parambuffer_write+0xf9600000000`062af5c0 00000001`40475aa2 : 407f4000`00000000 00000000`00000000 408f4000`00000000 00000001`4052f333 : MaxAudio!midibuffer_write+0x7f3700000000`062af600 00007ff8`0f3d0d43 : 00000000`071bd480 00000000`187fe900 00000000`00000010 00000000`071bd480 : Max!linklist_funall_break+0xe200000000`062af650 00007ff8`0f3e7bb5 : 00000000`00009f00 00000000`00000010 00000000`00000660 00000000`187fe900 : MaxAudio!midibuffer_write+0x83b300000000`062af740 00000000`1a861a4b : 00000000`00000000 00000000`00000001 00000000`17d38ee0 00000000`0045b800 : MaxAudio!timeevent_todictionary+0x581500000000`062af7a0 00007ff8`2d331bb2 : 00000000`3b3e39a0 00000000`3b3e39a0 00000000`00000000 00000000`00000000 : ad_mme+0x1a4b00000000`062aff00 00007ff8`2e2d7374 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ucrtbase!thread_start<unsigned int (__cdecl*)(void *),1>+0x4200000000`062aff30 00007ff8`2f69cc91 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0x1400000000`062aff60 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x21SYMBOL_NAME: function+855MODULE_NAME: functionIMAGE_NAME: function.mxe64STACK_COMMAND: ~46s; .ecxr ; kbFAILURE_BUCKET_ID: NULL_CLASS_PTR_READ_c0000005_function.mxe64!UnknownOS_VERSION: 10.0.19041.1BUILDLAB_STR: vb_releaseOSPLATFORM_TYPE: x64OSNAME: Windows 10IMAGE_VERSION: 9.0.6.0FAILURE_ID_HASH: {a8c56d61-e233-4538-a801-d42461f5ea04}Followup: MachineOwner---------
If you have a small patch to consistently reproduce the crash it's worth submitting a ticket with it + the crash log.
I can reproduce it semi-randomly with my patch. I don't have strictly deterministic reproduction steps. It's tricky. You have to basically move XY pad randomly to interpolate presets in a pattrstorage for some time until the function object cannot handle it anymore and crashes Max.
I have tried to simulate the random XY pad movement programmatically (seeded random) to find a deterministic scenario but with it didn't crash yet. I have been only able to reproduce it manually so far.
I think the dump log should tell the devs more. Especially this line:
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.OK so I have a suspect now. Not confirmed yet but I think frequency of data output from certain GUI objects can overload the function when modulating the interpolation of pattrstorage presets?
I have placed timer directly after the nodes object and it seems, at least with SIAI, it is possible to send values so that the timer reports 0. samples from time to time??? Seems nonsensical but that's what I read in the console. The number object does it too.
When I made sure there is at least 1 ms delay between the events with speedlim, I wasn't able to reproduce the crash anymore so I think there might be something to it even in case the timer were indeed nonsensical.
But I think the function should not crash anyway. There should be a safety check for this because it's very easy to crash it with live user input.
As @TFL mentions, a reduced patch with repro steps would be incredibly helpful.
Noted, Ben.
I am working on possible reproduction steps but it will take some time. Turns out this is a great opportunity to finally learn how to recall sample perfect automation recording (which should, in theory, eventually trigger the crash if my understanding of the problem is correct).
OK, so I have created (what I believe should be) a sample-accurate automation recording of preset interpolation that led to crash of the function object.
Unfortunately, replaying the automation does not lead to the crash :-( Maybe because when Max crashes the sfrecord~ object set to buffer 1 does not manage to sample the very last value or maybe even more values?
Or maybe the causes of the crash are more nuanced and not easily reproducible.
I can reproduce the crash everytime given enough time but the time to reproduce it varies greatly. Sometimes it takes only a couple of seconds of random movement of XY pad interpolating presets and sometimes I have to mess with it for 15 minutes. Eventually it will always crash the function object, but I don't understand the logic behind it.
Any debug suggestions that could lead me to precise reproduction steps?
I already have a full log of messages that lead to the crashes but I don't know how useful they would be for the devs because I am afraid minuscule timing differences can influence the results (but I have no real idea tbh).
I don't know how you trigger your interpolation in first instance and how you "replay" it, but maybe the difference between the two is scheduling. In your original patch, use [threadcheck] to know if a message runs in the main thread or the scheduler (high priority) thread. I guess you'll probably need to add a [schedule] in your replay method.
Any debug suggestions that could lead me to precise reproduction steps?
Take your patch causing the crash, delete half of it, see if the crash still happen, if it does then repeat, otherwise you know the culprit (or part of it) is in that half you just deleted, in which case you can try to delete other parts. Once you get to the smallest possible patch reproducing the crash, post here :)
I know this can be very cumbersome to do in complex patchs with many intricate parts, but it always pay off, and usually you don't even have to post the result here as you end up solving the problem yourself!
I don't know how you trigger your interpolation in first instance and how you "replay" it, but maybe the difference between the two is scheduling. In your original patch, use [threadcheck] to know if a message runs in the main thread or the scheduler (high priority) thread. I guess you'll probably need to add a [schedule] in your replay method.
Great suggestion, will try it.
OK, Ben (and others), I’ve got something useful.
It was hell. I’ve done a ton of testing. I’ve spent probably over 70 hours trying to find the reproduction steps and this is the closest I’ve been able to get.
It should crash every single time but the time it takes to crash is “random”. However I have been able to identify a combination of two key components that always leads to the crash and if one of the components is missing the crash cannot be reproduced. This, with combination of low-level knowledge of the function object, should give you at least something to work with.
Download all the required files below. Because I cannot upload a zip for whatever reason, you will have to manually put all the files to a folder and make sure the patcher can read both the external data files. The "x.json" file is a pattrstorage file. The "interpolation_data.txt" is a recorded sequence of gestural 4-preset-weights interpolation made with the nodes object.
1) Make sure Max is set to Overdrive and Audio Interrupt.
2) My scheduler settings and audio settings can be seen in the attached screenshots below.
3) Load the patch. Everything should be initialized automatically.
4) Turn on the audio processing!
5) Click on the big red/yellow button to replay a pattr interpolation sequence for the function object.
6) The crash should occur sometime in circa 35 minutes of the process running. Validate in the Event Log that it was indeed the function object that crashed Max - see a screenshot below with Windows example.
7) Now load Max again.
8) Make sure your Max settings are still properly setup.
9) Load the patcher again.
10) Disable the cable on the left side of the patcher (the one where the comment bubble says “Disable this cable to prevent the function from crashing.”).
11) Run the test again. It should run for probably 35 minutes without crashing but might get influenced by the speed of your computer.
12) The huge yellow message box on the right side of the patcher will get filled with final time values. That’s when you know the test finished successfully without crashing.
13) The same success should happen when you completely remove the pattr object and therefore disable the preset interpolation for the function object. Running the high frequency bang alone (on the left side of the patcher, coming from the phasor) to the function wasn’t able to crash Max in my tests. I let it run for an hour without issues.
14) So it is precisely the combination of both the bangs from the phasor to the function object and the preset interpolation.
Notes:
1) At first I thought that the rate of interpolation data itself was the cause for the crash but that was ruled out after I have created my custom pattr logic for the function object (notice, that I am not using the bindto connection from the pattr object to the function) to be able to speedlim the interpolated data.
2) I really really hope this is useful and devs will be able to fix it. I am burnt out, lol. Funny thing is that I don’t even own Max 9 yet so I won’t be benefiting from a potential fix anyway :-D
3) I have placed some key components of the patcher to the presentation mode so that should help you orientate better in the spaghetti. But to be sure, DO NOT run the test in the presentation mode. I think it can influence the timing slightly and therefore the results, but I am not sure yet.
bump, just want a reaction that somebody relevant read the repro steps. thx.
Nice break down!
If you want to make sure the staff reads what you did, you would better submit a ticket.
@BAEK, thanks so much for a stripped down patch.
First off, I had to remove the uzi logic, as it freezes Max immediately for me. I would not rely on notification from uzi's output to trigger itself without any deferral.
When I replace that with a metro 1 or similar, I'm unable to crash after letting it run for an hour+. I'm running Max 9.0.7, but i'm unaware of anything different in this department between Max 9.0.6 and Max 9.0.7.
However, I do get a crash when I close the patcher. This seems potentially unrelated to your crashes, and more about function getting a clear message in the high priority when the object has already been freed.
I also notice you have a rather high Signal Vector Size, and a rather low IO Vector Size. Does it behave any different for you if you use something else, say 512 / 64?
Side note, not that it should crash, but I'm suspicious of triggering the output of function with edge~ at such a high rate.
Generally speaking, if you have a bug report, it's always best to contact Support. Conversations on the Forum are great for tracking stuff down, getting tips, sharing info, etc, but dropping a note to Support is the only definitive way to get it into our system.
We will continue to investigate and let you know if we can find anything.
Hi Ben, thanks for the reply.
First off, I had to remove the
uzilogic, as it freezes Max immediately for me. I would not rely on notification from uzi's output to trigger itself without any deferral.
This is a correct behavior! I should have mentioned it. My Max freezes too. Unless your Max actually crashes or you don't hear the sound modulating with the automation data, do not remove the Uzi. Let it run "frozen" for those cca 35 minutes and "enjoy" the sound of osc~ modulating :-))) (we don't have an exact time but the sound modulation stopping is a good indicator it's over).
The patch has one single purpose: to crash the function object somewhat reliably. It's not supposed to make sense on its own or be optimal in any way. Its made so that you don't have to manually interpolate the presets with your mouse for half an hour each time you want to reproduce the bug in actual user interaction performance (slowly modulating the nodes object's XY pad for preset interpolation).
I also notice you have a rather high Signal Vector Size, and a rather low IO Vector Size. Does it behave any different for you if you use something else, say 512 / 64?
I suppose this is a typo and you mean it the other way around, correct? Do you want me to set a higher Signal Vector Size (you suggested 64 from my current 16) and lower IO Vector Size (you suggested 512 from my current 2048)? I can do that for the testing purposes but please note the setting would be absolutely unacceptable for me in real-use scenario. 64 Signal Vector Size (or higher) is too high for my real usecases as timing of my actual musical patches would suffer. Anyway, please confirm if I understand this bit you've suggested correctly. Thanks!
Side note, not that it should crash, but I'm suspicious of triggering the output of
functionwithedge~at such a high rate.
In my case, it will not crash by high rate edge~ alone, though, as I have explicitly stated in the repro steps. I suggested the issue is in the combination of the two factors. The high rate edge~ and the preset interpolation. When only one factor is in play I wasn't able to reproduce the crash in my testing.
(btw, the high rate function trigger has an actual musical usecase, because you can use the function as an oscillator shaper, and you should be able to hear that effect even during the repro steps when your Max "freezes" under the pressure of Uzi)
Generally speaking, if you have a bug report, it's always best to contact Support. Conversations on the Forum are great for tracking stuff down, getting tips, sharing info, etc, but dropping a note to Support is the only definitive way to get it into our system.
Noted, thanks. Should I do it now? Or should we clear something up before that yet?
Even though this crashes, it may not be the best test for your problem. The uzi outlet triggering itself may have it's own issues.
Sorry, yes, a lower IO Vector Size would be interesting to try.
I'm not discounting your idea that it is a combination of things, I'm just suggesting that this pattern of using edge~ to bang function may cause problems.
No need to make a Support ticket in this case, I'll continue to investigate.
In the meantime, it would be interesting to hear what practical outcome you are hoping for, as maybe there is a workaround and/or an alternative route to take to end up at the same place.
Ben, interesting news!
The I/O vector size indeed do have an impact!
I have just done the same test with the following audio settings (see the screenshot) and this is the very first time it did not crash.
So why do you think this happens? What led you to the initial idea to lower the I/O vector size? It's quite confusing to me as I would think that I/O should be irrelevant in this case but I am no expert at all.
I have just finished 4 complete tests with the audio settings from the previous post.
Not a single crash. No matter the Uzi and no matter the Max "freezing".
This should help us narrow down the culprit.
It is ticketed on our side. I've been able to crash and we have a good call stack to help with the investigations. The proximate caues for the crash is function getting triggered to output from a very rapid edge~ output, which crosses the audio to the scheduler domain. Aside from changing your audio setttings, another potential workaround could be to speedlim the output of edge~ before it gets to the function object. Cheers!
Ben, that's great news, thanks! Fingers crossed!
But I still don't understand why lowering the IO buffer helps in this case.