Hard crash while saving or modifying during Rain

[bbulkow]

I believe I was closing Chromatik while rain was playing

Ended up hard

[Chromatik 2022/11/18 23:54:54] Unhandled exception in Chromatik.main: LXLayeredComponent may not modify layers while looping, component: Rain[#50513][/lx/mixer/channel/1/pattern/7] looping: RainDrop[#71506][/layer/1] dispose: null
java.lang.IllegalStateException: LXLayeredComponent may not modify layers while looping, component: Rain[#50513][/lx/mixer/channel/1/pattern/7] looping: RainDrop[#71506][/layer/1] dispose: null
at heronarts.lx.LXLayeredComponent.checkForReentrancy(LXLayeredComponent.java:126)
at heronarts.lx.LXLayeredComponent.dispose(LXLayeredComponent.java:170)
at heronarts.lx.pattern.LXPattern.dispose(LXPattern.java:450)
at heronarts.lx.mixer.LXChannel.dispose(LXChannel.java:1059)
at heronarts.lx.mixer.LXMixerEngine.removeChannel(LXMixerEngine.java:712)
at heronarts.lx.mixer.LXMixerEngine.dispose(LXMixerEngine.java:1095)
at heronarts.lx.LXEngine.dispose(LXEngine.java:1287)
at heronarts.lx.LX.dispose(LX.java:603)
at heronarts.glx.GLX.dispose(GLX.java:713)
at heronarts.glx.GLX.run(GLX.java:203)
at heronarts.lx.studio.Chromatik.main(Chromatik.java:283)

This requires essentially a force quit to get out of

[mcslee]

Are you able to reproduce this manually? I am not getting this error when quitting while running Rain. And based upon the internal state that would need to be set for this error to occur, it seems like there would have had to be a crash previously in the underlying pattern that left it in a state where it still believes it's iterating over its layers.

Context - the flag that causes this issue gets set here on line 105, when a pattern loops over its layers:
https://github.com/heronarts/LX/blob/dev/src/main/java/heronarts/lx/LXLayeredComponent.java#L105

When the for loop finishes, it's cleared at line 114:
https://github.com/heronarts/LX/blob/dev/src/main/java/heronarts/lx/LXLayeredComponent.java#L114

This crash would seem to suggest that line 114 didn't get reached during operation of the Rain pattern.

I wonder if you can go dig up the full Chromatik log file from this run and we can find any clues there. Look in the ~/Chromatik/Logs folder and there are timestamped log files for each invocation of Chromatik.

You'd be looking for the last one that started before this time:
[Chromatik 2022/11/18 23:54:54]

If you're able to locate that, can you share the file here?

[mcslee]

I've added a guard against this problem in the underlying LX library:
heronarts/LX@262625d

That'll be included when I next update the Chromatik builds for you.

But I still think the cause of this in your case was most likely a prior error inside one of the RainDrop instances of the Rain pattern. I think it's still worth you digging up that log, as I suspect there is some condition in which the Rain pattern breaks.

[cswales]

@mcslee: This problem has only been seen when we're modifying the underlying model. Many of the patterns - including rain - are not resilient to changes in the model during runtime. This was not a problem that we had previously, since you didn't used to be able to change the patterns during runtime. When porting the patterns, I elected not to fix this issue - too many patterns, too much work.

[mcslee]

Ah, okay - yeah I'm not surprised to hear that. Any patterns that init helper data based upon assumptions from the size of the initial model passed in are definitely liable to crash in bad ways if they don't handle onModelChanged - and it's definitely a bit of a pain to audit that.

The fix I dropped in will at least cause this internal exception to stop happening, but it won't stop patterns/effects from having already crashed out.

FYI - patterns/effects that throw uncaught exceptions (whether due to this, or whatever else) shouldn't take the whole program down. The engine will catch that, set a crashed flag and then stop invoking the run calls on those patterns/effects. So you'll get broken behavior (it'll just stop rendering new things) but the rest of the program will continue.

Gonna assign this one back to you guys as from here on out it's really a case of auditing entwined code that doesn't handle the model being dynamic.