There is a CME on this line: MixinChunkRendererRegion.java#L45

This was first reported on the optifabric issue tracker here but it has since been reproduced without optifine. (I think optifine is just making it more common).

crash-2019-09-12_22.24.59-client.txt

As for a way to reproduce it without optifine im not sure of one. One possible idea would be the world lagging and it happening when it was trying to catch up? (suggestion from Fudge on discord)

For those of you experiencing the issue, please try the test build and report back.

I suspect this happens because other mods are updating the per-chunk block entity map outside of the main client thread. Optifine may be the worst offender but any mod could do it. It's even possible that Mojang's network packet handlers aren't particularly good at synchronizing those changes to the main thread.

Given that we can't prevent the practice, solution will be to make the iteration thread-safe. Will look at it.

Edit: another vanilla cause could be restarted/cancelled chunk rebuilds, which would be more common in a high-update scene and may even be perversely more frequent with higher frame rates.

Afai see the rebuilds are done only on the render/client thread instead of on chunk batchers; the access to block entities are supposingly thread-safe in most cases. Imo if we make the collection thread safe, the collection for block entities may be a concurrent hash map instead?

I won't make changes to vanilla data structures unless there is no other choice - too likely to break. I have another notion I will try first.

Hmmm, plan A (inspect block state array for blocks that have block entities and query those) is not performant.

I might be able to make it work if I could do more fine-grained ASM in the existing logic, but that's really not an option. Open to suggestions. Again, would prefer to avoid changing vanilla structures in API.

We can just make a debug mod and use optifine and catch this cme again to see what's writing to the block entity map

For Optifine I'm almost certain it builds the chunk caches off-thread as an optimization. But now this is happening without OF, so something else is also doing it, apparently. Chasing down offenders isn't a treadmill I want to be on.

One suggestion, can this thing log those exceptions so we can see how often it triggers (and that it triggers and prevents a crash)?

If it remains, will add logging. Currently considering removing the code that causes the crash entirely.

Should be fixed in API 0.4