max patch constantly crashing randomly, suspect (multiple) udpreceive.

    Sep 01 2016 | 4:58 pm
    I've been talking to cycling74 support about this for over a year and they've been unable to help, so I'm posting here in case someone has any advice.
    My MAX patch is crashing randomly and I'm 99.99% it's related to udpreceive, particularly multiple udpreceives at the same time (listening on different ports). I'm running latest Max 7.2.4, same problem on both windows and mac.
    My patch used to receive OSC from 4x computers (all on different ports). 3x of them running a kinect2 tracker and streaming skeleton OSC at 30fps (this used to be another MAX patch, but later I switched to a custom C++ app with properly formatted OSC msgs. crash would happen in either instance). The 4th computer is sending showcontrol OSC (scene / preset change triggers etc). In this setup my patch would always crash, sometimes after 2 minutes of running, sometimes after 5 hours. At completely random times, with no noticeable 'trigger' events to cause the crash (i.e. when nothing noticeable was happening). I never managed to detect a pattern, and I'm usually good at isolating problems.
    Suspecting the udpreceive (since that's the only thing that's always running, even when nothing is happening), I wrote a standalone C++ application to receive the 3x skeleton OSC streams, consolidate and transform them into a single space, and send via OSC to the MAX patch. So the MAX patch now has only 1 incoming stream of skeleton OSCs, not 3 as it did before. This stopped the crashing, almost completely...
    If I don't run showcontrol OSC, the patch doesn't crash anymore (before when I had 3x skeleton OSC streams it would crash even if I didn't run showcontrol).
    But if I do send OSC showcontrol triggers, the patch crashes, sometimes. Maybe 1 in 20, to 1 in 200 cues causes the patch to crash. It's very erratic, so impossible to replicate consistently.
    I'm using Qlab to send the showcontrol OSC (I've also tried Ableton Live + Max for Live, and get the same results). The OSC messages I'm sending are very simple, Just triggers like /reset 1, /scene 3 etc. And they just trigger various bangs in my patch. Manually triggering those same bangs does not cause the patch to crash, ever. I've clicked them hundreds if not thousands of times over the past year. Sending OSC to trigger those exact same bangs does cause MAX to crash, occasionally :/
    Based on all of this I'm suspecting something to do with multiple udpreceive, and perhaps some kind of race condition when they receive at the exact same time or something. I tried to replicate this in a very minimal repro setup, but didn't get any crashes, so I'm not sure. I'm hoping someone else might have had similar experience and able to nail the exact cause. Any suggestions welcome! (Latest crash report attached).
    P.S. I realize I could try having only one udpreceive for the entire project, and listen on a single port with different address prefixes for skeletons and showcontrol. But that feels like a hack workaround and not a solution - though I will definitely do that before the show goes on the road if the problem isn't resolved by then.
    P.P.S As much as I love MAX, this is severely putting me off using closed-source software. I've had this problem for over a year and I've shared my full project with cycling74. if I'm paying for software I either expect it to work, or if bugs do happen (which they inevitably will) and can't be addressed by the developers for whatever reason, I expect to be able to debug and fix it myself - or at least identify the problem. It took me months to figure out it might be udpreceive (prior to that I spent months trying to identify another crash bug which turned out to be related to dicts being updated and viewed at the same time in different windows), but without having access to the src it's a PITA.
    thx for reading this far!

    • Sep 01 2016 | 5:04 pm
      deferlow right after your udpreceives?
    • Sep 01 2016 | 9:18 pm
      Thanks for the suggestion! I will try that. Out of curiosity (so that I learn), why do you think that might fix it?
    • Sep 02 2016 | 2:17 am
      if I’m paying for software I either expect it to work, or if bugs do happen (which they inevitably will) and can’t be addressed by the developers for whatever reason, I expect to be able to debug and fix it myself – or at least identify the problem.
      Processes in Max are handled on 'threads' that schedule the order of operations. [udpreceive] operates on a high priority scheduler while Jitter and OpenGL are low priority. [deferlow] makes [udpreceive] wait it's turn.
      I'm not so sure than an open source alternative would make it any easier to trouble shoot this sort of thing. It would still require due diligence on your part to search for answers. The problem has been covered more than once on the forum, so maybe changing your troubleshooting routine might help. Be sure to use google to search for posts (the forum search tool is weak). Either precede search strings with "cycling74" or use the google site: query option. You can bookmark your query setup so that it's as easy as any other search. Hope that helps.