Rubisk

There was some error complaining about incremental CMS being deprecated and most likely removed soon, so I took it out (after figuring out what it actualy was). No crashes ever since (3 days). Took quite a while to figure out how to disable it without cutting my FPS down to 10% of normal.

I also found MC-69351. That issue is different from mine, since that one is caused by broken graphics drivers, and this is a crash within a JVM core process/source code issue. (look at the difference in the Problematic frame)

So, after 40 hours+ of research, I came to the conclusion that the deprecated Incremental CMS garbage-collector is causing this issue.

I'm not a java expert, but I would recommend Mojang to disable this by default in the JVM arguments section. Normal CMS garbage-collection is still required, but the incremental version seems to crash some processors (at least mine).

I'll drop a link down to the documentation for CMS garbage-collectors for more information.
http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html

(quick fix: Remove -XX:+CMSIncrementalMode out of your JVM arguments in the Edit Profile section. Make sure to keep -XX:+UseConcMarkSweepGC in there or your FPS will drop drastically.

In my independent bug report Searge marked it as fixed, not sure if he misclicked the duplicate or actually fixed it but we'll see: MC-79714

@Qmagnet

What I think is happening is the following:

World gets opened. Scores get read from the scoreboard.dat file, and cached to the right entities. Then the scoreboard is created, scores owner Id's get cut off.
When you TEST for an entity using a selector, it'll look try obtain the score through the scoreboard. It'll find some names, but those are names, not UUIDs, due to them getting cut off. Therefore, it won't recognize the entity.
If you add one to the score of an entity, it'll locate the entity without using the scoreboard, add 1 to it's score (which got cached to the proper entity before creating the scoreboard), and add 1 to the respective UUID of the entity. Since the score for the entity is still what it was, but just misinterpreted by the scoreboard that got created upon reloading it from the scoreboard.dat file, it's not going to get messed up in anyway.

I've looked through the scoreboard.dat file, and they do get saved correctly with a proper UUID: http://gyazo.com/59144fbaf6329be43e9ded6a6ede5454
The bad code is probably in loading the scoreboard from the memory, not in loading the scores for each individidual entity. I don't have a good enough understanding of the MC code to really specify where exactly it's messed up, but it's probably pretty easy for Mojang to look through their commits and find it with these hints.

Through reddit I found the duplicate, I'll close this https://bugs.mojang.com/browse/MC-79632
Hmm apparently I can't close this :/

Confirmed as of Minecraft 1.8.3

I'll try get a complete core dump this weekend, maybe that will clear some stuff up (probably won't, unfortunately).

I've done some research myself, doesn't look like it's a line of code causing the crash. The instructions it crashes at seem to be completely different most of the time...

Added some more JVM logs, so you can see that it's not the same everytime.

Added a clean Luancher Log and Game output file, hope it helps.

http://pastebin.com/24ZJ53DV

Important stuff is at the end, I had to restart the game a few times doing some tests so there's some junk at the top.

Confirmed of 1.8.2-pre1.

Here's a bunch of stuff that might help the developers out.

1) Reloading the world doens't seem to cause any issues, redstone always continues.

2) Running away from the chunks, the walking back, causes all the 20Hz redstone clocks to stop. It will stop all redstone clocks if you unload at the right tick.

3) Teleporting away from the chunks, then teleporting back, causes a specific position of redstone clocks to stop. Every chunk seems to have some sort of binary yes/no value, that defines whether or not a redstone clock stops if unloaded in the correct tick when you teleport away. http://imgur.com/pqnreZg this is a visualisation of all chunks that stop. Wherever water spilled, clocks in that chunk stopped. The most bottomleft chunk is (-1,-1), going up X to the left and up Z upwards. Notice that wherever chunkPosX = chunkPosZ the clocks do not stop.

How to reproduce: Setup a 20hz fill clock. Put two command blocks on it. One sets a block to flowing water, somewhere up in the air. Surround the flowing water by glass on all corresponding Y positions to prevent it from spilling to the sides. The second command block sets the block below the flowing_water block to air. Whenever the fill clock stops running, the water spills everywhere.

Something else to note, according to the command block output, it seems that redstone updates process one tick after the chunk blocks unload. This causes all redstone activity to give a "can't access stuff outside the world" error, and so the clock stops. If the clock continues, the redstone is saved as a tiletick (like it should), but if it stops, the command blocks show the "can't access stuff outside the world error", and only the water gets saved as a tiletick. I've been digging in the decompiled code for a bit, but my java knowledge isn't good enough to really find out what's causing this behavior.

Confirmed as of 1.8.1 full release.

https://www.youtube.com/watch?v=VHC6SpMsEkI&feature=youtu.be

Unfortunately, I can reproduce about 50% of the time. Seems to only happen in flowing water...

apparently the issue doesn't occur on old superflat worlds...

Apparently copying the level.dat from a non-superflat world to a superflat world fixes it. Changing the generatorName
NBT-tag to default doesn't fix it, nor does removing the generatorOptions. Must be another tag doing it, but it's defintely one in the level.dat...

Unconfirmed, turns out you can't execute on death mobs unfortunately 😉

This isn't fixed in 14w28a, does this mean in will be fixed in 14w28b or has mojang derped?

Confirmed.

Mods, why hasn't this bug been assigned yet after 2-3 weeks. It's a pretty major issue, and I'm kinda confused that it still hasn't got a mojangster assigned. Not to say you aren't doing good work, but there's a lot of people waiting on a fix 😉

Other then that, confirmed for 14w28a.