DoesNotUnderstand error causing a crash

Development
10

My real case

Here’s what I know:

  • The offending operation is being triggered by an OSC message (via OSCFunc, not the alternate code path that I wrote in the first message), e.g. ['/sceneMenu', 11.0]. The OSC layer has nothing insane going on.

  • The OSC response is to pull a function out of an array and evaluate it.

  • At this point, I’ve seen two distinct crashes:

    • The bp.v.chan crash. Here, the func being evaluated does BP(\something) =>.aNumber t where t calls into the function shown here, where v doesn’t exist so .chan throws an error, and it crashes then. TBH this is not a super-deep stack: OSCFunc stuff (6 stack frames), a protect, then the BP() =>... does a second protect, then dies.
    • A crash loading a VSTPlugin. Here, I didn’t have a crash when I just wrote the logic directly into the player object. But then I needed to load a couple of them, so I abstracted that part out into a separate function, and the combination of OSC + scene handler + calling that function crashed, where OSC + scene handler + VSTPlugin logic written inline did not crash.

  • Even more strangely, if I defer the evaluation of the scene function, then the crashes disappear. But the AppClock overhead in terms of stack frames is heavier than OSCFunc’s (11 frames vs 6)!

  • If I trigger the scene update by manual code instead of OSC, the crash disappears.

  • If I run my live set-up in a command-line sclang, then the original code (without the defer workaround) fails to crash. So I can’t get any stack traces from gdb :face_with_symbols_over_mouth: :face_with_symbols_over_mouth: :face_with_symbols_over_mouth:

Beyond that, I have no idea. I don’t see what is so exotic about any of this that it should take down the interpreter. And, since the boundaries of the crashing scenario are not known, I can only test my code before a gig and hope that it behaves the same on stage as at home.

hjh