Rare CME in BoulderSolver

[rapid blade]

catching
java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:911) ~[?:1.8.0_442]
at java.util.ArrayList$Itr.next(ArrayList.java:861) ~[?:1.8.0_442]
at gg.skytils.skytilsmod.features.impl.dungeons.solvers.BoulderSolver$update$1.invokeSuspend(BoulderSolver.kt:153) ~[BoulderSolver$update$1.class:?]
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33) [Essential%20(forge_1.8.9).processed.jar:?]
at gg.skytils.ktx-coroutines.DispatchedTask.run(DispatchedTask.kt:106) [DispatchedTask.class:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1147) [?:1.8.0_442]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_442]
at java.lang.Thread.run(Thread.java:750) [?:1.8.0_442]

[midnight siren]

tile entity being modified whilst we iterate it

don't imagine that happens all too much

[sharp anvil]

shouldn't happen though because I thought tick tasks run on game thread

[rapid blade]

Ah I didn't actually check the exact line the error happened so i did not see that it happened on the ArrayList of Tile Entities, I assumed it was because of the ArrayList fields solver itself was using. In that case it might even be a vanilla error, although I'm not sure yet.

[rapid blade]

I have no idea since I don't know the codebase all that much but I see many errors being tagged on pool-23-thread-1 style names instead of the client thread which suggests code running on other threads but there is a very high chance its some coroutine magic since I don't have experience with coroutines.

[sharp anvil]

Where are the thread names

[rapid blade]

I only have the stacktrace noted down unfortunately but I remember it was something like pool-23-thread-1 like all the other errors I had seen in ST so far. I can search my log files to find it if the specific thread name is going to be helpful.

[sharp anvil]

If it was on like the side of the logs I believe that's from where it got printed

[rapid blade]

It was on the side yes, but that usually shows me accurate thread names and not something like "Logging Thread" so I assumed it was the source of truth for what thread code is running at, but you are right that it might be wrong

[sharp anvil]

https://github.com/Skytils/SkytilsMod/blob/ed5c63faa7ddf46a58d13ef40ebeb1ebfbc314c3/src/main/kotlin/gg/skytils/skytilsmod/core/tick.kt#L61
I think it prints from the coroutine thread

[sharp anvil]

Shouldn't be a vanilla error if it actually runs on the correct thread - it's more likely it's from some other mod

Or another class modifies it

[rapid blade]

Happened with IceFillSolver as well.

[17:49:57] [DefaultDispatcher-worker-1/ERROR]: catching
java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:911) ~[?:1.8.0_452]
at java.util.ArrayList$Itr.next(ArrayList.java:861) ~[?:1.8.0_452]
at gg.skytils.skytilsmod.features.impl.dungeons.solvers.IceFillSolver$1$1.invokeSuspend(IceFillSolver.kt:59) ~[IceFillSolver$1$1.class:?]
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33) [Essential%20(forge_1.8.9).processed.jar:?]
at gg.skytils.ktx-coroutines.DispatchedTask.run(DispatchedTask.kt:104) [DispatchedTask.class:?]
at gg.skytils.ktx-coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:584) [CoroutineScheduler.class:?]
at gg.skytils.ktx-coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:811) [CoroutineScheduler$Worker.class:?]
at gg.skytils.ktx-coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:715) [CoroutineScheduler$Worker.class:?]
at gg.skytils.ktx-coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:702) [CoroutineScheduler$Worker.class:?]

I believe is caused by me having low view distance - as I walk into the puzzle room, some elements are likely being removed from loadedTileEntities from the unloaded chunks behind (in the Client thread - that's not the issue). The issue happens because, even though its not modifying but only reading, CME still triggers because an entry is removed while we are iterating.

The fix I believe is to create a copy of the loadedTileEntityList before going into the scope of job = Skytils.launch { .. code where it uses the list at some point .. } in IceFillSolver (or BoulderSolver for that matter), and use that instead of accessing the loadedTileEntityList inside the coroutine thread.