Creating a new world fails "Writing into PalettedContainer from multiple threads" - Bug in JRE 1.8.0_25
This bug seems to be caused by a JVM bug:
We've identified the big 1.13-pre4 crash as a bug in Java itself! We have a fix lined up, but it's always exciting to be reminded that the JRE isn't infallible.
It looks like at least Java 1.8.0_51 and newer versions should solve this issue (used by default by the launcher).
See MC-138125 if you experience this bug with an up to date Java version.
The bug
When creating a new world on 1.13-pre4, the first time I loaded up a new world, the game hung up on the "loading world" screen. The second time, it loaded 25% of the spawn area. Closing the game and loading the world progresses the "preparing the spawn area" screen between zero and four percent each time. After ten times attempting to load a new world, I'm at 36%.
Environment
Windows 10 64-bit
Java Version 8, update 171
6GB VRAM (crossfire)
Fullscreen and Windowed Minecraft with varied graphics settings.
Linked Issues
is duplicated by22
Created Issue:
Creating a new world fails
When creating a new world on 1.13-pre4, the first time I loaded up a new world, the game hung up on the "loading world" screen. The second time, it loaded 25% of the spawn area. Closing the game and loading the world progresses the "preparing the spawn area" screen between zero and four percent each time. After ten times attempting to load a new world, I'm at 36%.
Environment
Windows 10 64-bit
Java Version 8, update 171
6GB VRAM (crossfire)
Fullscreen and Windowed Minecraft with varied graphics settings.
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
relates to
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
When creating a new world on 1.13-pre4, the first time I loaded up a new world, the game hung up on the "loading world" screen. The second time, it loaded 25% of the spawn area. Closing the game and loading the world progresses the "preparing the spawn area" screen between zero and four percent each time. After ten times attempting to load a new world, I'm at 36%.
When creating a new world on 1.13-pre4, the first time I loaded up a new world, the game hung up on the "loading world" screen. The second time, it loaded 25% of the spawn area. Closing the game and loading the world progresses the "preparing the spawn area" screen between zero and four percent each time. After ten times attempting to load a new world, I'm at 36%.
1.13-pre5Description: Writing into PalettedContainer from multiple threads java.lang.IllegalStateException at bmo.b(SourceFile:43) at bmo.a(SourceFile:110) at bmi.a(SourceFile:68) at bmp.a(SourceFile:167) at tc.a(SourceFile:225) at brc.a(SourceFile:133) at brc.a(SourceFile:42) at brc.a(SourceFile:14) at buw.a(SourceFile:21) at buw.a(SourceFile:14) at bol.a(SourceFile:27) at axx.a(SourceFile:515) at blx.a(SourceFile:109) at tl.a(SourceFile:12) at tk.a(SourceFile:35) at bmb.a(SourceFile:95) at tr.a(SourceFile:62) at tr.a(SourceFile:25) at ace$a.a(SourceFile:130) at ace$a$$Lambda$1905/1724406835.apply(Unknown Source) at java.util.concurrent.CompletableFuture$AsyncApply.exec(CompletableFuture.java:501) at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289) at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:902) at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1689) at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1644) at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
When creating a new world on 1.13-pre4, the first time I loaded up a new world, the game hung up on the "loading world" screen. The second time, it loaded 25% of the spawn area. Closing the game and loading the world progresses the "preparing the spawn area" screen between zero and four percent each time. After ten times attempting to load a new world, I'm at 36%.
1.13-pre5Description: Writing into PalettedContainer from multiple threads java.lang.IllegalStateException at bmo.b(SourceFile:43) at bmo.a(SourceFile:110) at bmi.a(SourceFile:68) at bmp.a(SourceFile:167) at tc.a(SourceFile:225) at brc.a(SourceFile:133) at brc.a(SourceFile:42) at brc.a(SourceFile:14) at buw.a(SourceFile:21) at buw.a(SourceFile:14) at bol.a(SourceFile:27) at axx.a(SourceFile:515) at blx.a(SourceFile:109) at tl.a(SourceFile:12) at tk.a(SourceFile:35) at bmb.a(SourceFile:95) at tr.a(SourceFile:62) at tr.a(SourceFile:25) at ace$a.a(SourceFile:130) at ace$a$$Lambda$1905/1724406835.apply(Unknown Source) at java.util.concurrent.CompletableFuture$AsyncApply.exec(CompletableFuture.java:501) at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289) at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:902) at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1689) at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1644) at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
[Mojang] Nathan Adams on Twitter:
We've identified the big 1.13-pre4 crash as a bug in Java itself! We have a fix lined up, but it's always exciting to be reminded that the JRE isn't infallible.
Creating a new world fails "Writing into PalettedContainer from multiple threads"
Creating a new world fails "Writing into PalettedContainer from multiple threads" - Bug in JRE 1.8.0_25
When creating a new world on 1.13-pre4, the first time I loaded up a new world, the game hung up on the "loading world" screen. The second time, it loaded 25% of the spawn area. Closing the game and loading the world progresses the "preparing the spawn area" screen between zero and four percent each time. After ten times attempting to load a new world, I'm at 36%.
1.13-pre5Description: Writing into PalettedContainer from multiple threads java.lang.IllegalStateException at bmo.b(SourceFile:43) at bmo.a(SourceFile:110) at bmi.a(SourceFile:68) at bmp.a(SourceFile:167) at tc.a(SourceFile:225) at brc.a(SourceFile:133) at brc.a(SourceFile:42) at brc.a(SourceFile:14) at buw.a(SourceFile:21) at buw.a(SourceFile:14) at bol.a(SourceFile:27) at axx.a(SourceFile:515) at blx.a(SourceFile:109) at tl.a(SourceFile:12) at tk.a(SourceFile:35) at bmb.a(SourceFile:95) at tr.a(SourceFile:62) at tr.a(SourceFile:25) at ace$a.a(SourceFile:130) at ace$a$$Lambda$1905/1724406835.apply(Unknown Source) at java.util.concurrent.CompletableFuture$AsyncApply.exec(CompletableFuture.java:501) at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289) at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:902) at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1689) at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1644) at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
[Mojang] Nathan Adams on Twitter:
We've identified the big 1.13-pre4 crash as a bug in Java itself! We have a fix lined up, but it's always exciting to be reminded that the JRE isn't infallible.
When creating a new world on 1.13-pre4, the first time I loaded up a new world, the game hung up on the "loading world" screen. The second time, it loaded 25% of the spawn area. Closing the game and loading the world progresses the "preparing the spawn area" screen between zero and four percent each time. After ten times attempting to load a new world, I'm at 36%.
[Mojang] Nathan Adams on Twitter:
We've identified the big 1.13-pre4 crash as a bug in Java itself! We have a fix lined up, but it's always exciting to be reminded that the JRE isn't infallible.
Superflat worlds can be generated without a problem
is duplicated by
relates to
is duplicated by
relates to
is duplicated by
is duplicated by
When creating a new world on 1.13-pre4, the first time I loaded up a new world, the game hung up on the "loading world" screen. The second time, it loaded 25% of the spawn area. Closing the game and loading the world progresses the "preparing the spawn area" screen between zero and four percent each time. After ten times attempting to load a new world, I'm at 36%.
[Mojang] Nathan Adams on Twitter:
We've identified the big 1.13-pre4 crash as a bug in Java itself! We have a fix lined up, but it's always exciting to be reminded that the JRE isn't infallible.
Clarification noteThis bug seems to be caused by a JVM bug:
We've identified the big 1.13-pre4 crash as a bug in Java itself! We have a fix lined up, but it's always exciting to be reminded that the JRE isn't infallible.
It looks like at least Java 1.8.0_51 and newer versions should solve this issue (used by default by the launcher).
See
MC-138125if you experience this bug with an up to date Java version.The bug
When creating a new world on 1.13-pre4, the first time I loaded up a new world, the game hung up on the "loading world" screen. The second time, it loaded 25% of the spawn area. Closing the game and loading the world progresses the "preparing the spawn area" screen between zero and four percent each time. After ten times attempting to load a new world, I'm at 36%.
relates to
is duplicated by
ah, looks like MC-132073, so a few people DID notice this ... good
It's not just MC-132073, the issues are persistent well beyond the initialization of the existing world. I'm attaching my world to this comment in a Google drive folder. If you download the save and teleport to 120, 81,1273, you'll get a good idea of the performance woes.
https://drive.google.com/open?id=10Q6nVFBvznfYhJ58C8naqS4W4QqDxwek
Now that MC-132073 has been fixed (some time ago), please check whether or not this issue persists in pre5.
Does MC-132073 explain your issue? (JVM bug, fix in new launcher + new java)
Can you try if the issue still occurs when you use Java Version 8, update 51?
Edit: Yes, I know it's an older version, but it's what the launcher recommends. If it still doesn't work with that version, we know that there's another bug that's definitely distinct from MC-132073, even though the crash report is nearly identical.
This report is only for Java version 1.8.0_51 or higher. See MC-132073 for older Java versions.
1. I just flew and then some chunks failed to load
2. I tried to fly away and then some chunks shown in-game, but not in 'problematic' zone
3. I flew into 'problematic' zone again and chunks shown
4. Game somehow bugged and some chunks became invisible
5. Some invisible chunks reappeared(they blinked)
6. I flew into 'void' zone, where chunks still not generated/shown
7. Everything disappeared, i tried to fly back to zone, that was visible
8. Game crashed
I made some tests:
Java 11: 2 runs, 2 crashes
Java 8: 1 run, 0 crashes, but same buggy chunk loading/generating behavior
---- Minecraft Crash Report ---- // Everything's going to plan. No, really, that was supposed to happen. Time: 10/27/18, 5:19 AM Description: Writing into PalettedContainer from multiple threads java.lang.IllegalStateException at boo.b(SourceFile:42) at boo.a(SourceFile:109) at boi.a(SourceFile:44) at bop.a(SourceFile:181) at bpt.d(SourceFile:121) at bnw.c(SourceFile:145) at boa.a(SourceFile:119) at boa.i(SourceFile:37) at boa.a(SourceFile:200) at ty.a(SourceFile:457) at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072) at java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479) at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020) at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656) at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594) at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177) A detailed walkthrough of the error, its code path and all known details is as follows: --------------------------------------------------------------------------------------- -- Head -- Thread: Server thread Stacktrace: at boo.b(SourceFile:42) -- Thread dumps -- Details: Thread dumps: Chunk Batcher 2: at java.base@11.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@11.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@11.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) at java.base@11.0.1/java.util.concurrent.PriorityBlockingQueue.take(PriorityBlockingQueue.java:547) at app//dab.d(SourceFile:170) at app//dac.run(SourceFile:41) at java.base@11.0.1/java.lang.Thread.run(Thread.java:834) Snooper Timer: at java.base@11.0.1/java.lang.Object.wait(Native Method) at java.base@11.0.1/java.lang.Object.wait(Object.java:328) at java.base@11.0.1/java.util.TimerThread.mainLoop(Timer.java:527) at java.base@11.0.1/java.util.TimerThread.run(Timer.java:506) Chunk Batcher 7: at java.base@11.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@11.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@11.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) at java.base@11.0.1/java.util.concurrent.PriorityBlockingQueue.take(PriorityBlockingQueue.java:547) at app//dab.d(SourceFile:170) at app//dac.run(SourceFile:41) at java.base@11.0.1/java.lang.Thread.run(Thread.java:834) Netty Local Client IO #0: at java.base@11.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@11.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@11.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) at java.base@11.0.1/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433) at app//io.netty.util.concurrent.SingleThreadEventExecutor.takeTask(SingleThreadEventExecutor.java:238) at app//io.netty.channel.DefaultEventLoop.run(DefaultEventLoop.java:52) at app//io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:884) at java.base@11.0.1/java.lang.Thread.run(Thread.java:834) Chunk Batcher 5: at java.base@11.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@11.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@11.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) at java.base@11.0.1/java.util.concurrent.PriorityBlockingQueue.take(PriorityBlockingQueue.java:547) at app//dab.d(SourceFile:170) at app//dac.run(SourceFile:41) at java.base@11.0.1/java.lang.Thread.run(Thread.java:834) Finalizer: at java.base@11.0.1/java.lang.Object.wait(Native Method) at java.base@11.0.1/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:155) at java.base@11.0.1/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:176) at java.base@11.0.1/java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:170) Netty Server IO #1: at java.base@11.0.1/sun.nio.ch.EPoll.wait(Native Method) at java.base@11.0.1/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120) at java.base@11.0.1/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124) at java.base@11.0.1/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:136) at app//io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:756) at app//io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:411) at app//io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:884) at java.base@11.0.1/java.lang.Thread.run(Thread.java:834) Server thread: at app//boo.a(SourceFile:205) at app//bot.a(SourceFile:554) at app//bot.a(SourceFile:323) at app//ty.a(SourceFile:550) at app//ty.b(SourceFile:622) at app//ty.a(SourceFile:601) at app//tz.a(SourceFile:177) at app//net.minecraft.server.MinecraftServer.b(SourceFile:730) at app//net.minecraft.server.MinecraftServer.a(SourceFile:664) at app//djq.a(SourceFile:125) at app//net.minecraft.server.MinecraftServer.run(SourceFile:568) at java.base@11.0.1/java.lang.Thread.run(Thread.java:834) Resource IO {0}: at java.base@11.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@11.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@11.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) at java.base@11.0.1/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433) at java.base@11.0.1/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1054) at java.base@11.0.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114) at java.base@11.0.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base@11.0.1/java.lang.Thread.run(Thread.java:834) Thread-1: at java.base@11.0.1/java.lang.Thread.sleep(Native Method) at app//paulscode.sound.SimpleThread.snooze(SimpleThread.java:196) at app//paulscode.sound.CommandThread.run(CommandThread.java:133) Light executor 0: at app//bzp.b(SourceFile:158) at app//bzw.a(SourceFile:79) at app//bzp.b(SourceFile:197) at app//bzr.a(SourceFile:117) at app//bzu.a(SourceFile:54) at app//ud.b(SourceFile:105) at app//ud$$Lambda$2086/0x00000008007ea840.run(Unknown Source) at java.base@11.0.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base@11.0.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base@11.0.1/java.lang.Thread.run(Thread.java:834) Chunk Batcher 3: at java.base@11.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@11.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@11.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) at java.base@11.0.1/java.util.concurrent.PriorityBlockingQueue.take(PriorityBlockingQueue.java:547) at app//dab.d(SourceFile:170) at app//dac.run(SourceFile:41) at java.base@11.0.1/java.lang.Thread.run(Thread.java:834) Timer hack thread: at java.base@11.0.1/java.lang.Thread.sleep(Native Method) at app//cjk$1.run(SourceFile:608) Java2D Disposer: at java.base@11.0.1/java.lang.Object.wait(Native Method) at java.base@11.0.1/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:155) at java.base@11.0.1/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:176) at java.desktop@11.0.1/sun.java2d.Disposer.run(Disposer.java:144) at java.base@11.0.1/java.lang.Thread.run(Thread.java:834) Reference Handler: at java.base@11.0.1/java.lang.ref.Reference.waitForReferencePendingList(Native Method) at java.base@11.0.1/java.lang.ref.Reference.processPendingReferences(Reference.java:241) at java.base@11.0.1/java.lang.ref.Reference$ReferenceHandler.run(Reference.java:213) ObjectCleanerThread: at java.base@11.0.1/java.lang.Object.wait(Native Method) at java.base@11.0.1/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:155) at app//io.netty.util.internal.ObjectCleaner$1.run(ObjectCleaner.java:54) at app//io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.base@11.0.1/java.lang.Thread.run(Thread.java:834) Thread-2: at java.base@11.0.1/java.lang.Thread.sleep(Native Method) at app//paulscode.sound.SimpleThread.snooze(SimpleThread.java:196) at app//paulscode.sound.StreamThread.run(StreamThread.java:98) Chunk Batcher 1: at java.base@11.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@11.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@11.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) at java.base@11.0.1/java.util.concurrent.PriorityBlockingQueue.take(PriorityBlockingQueue.java:547) at app//dab.d(SourceFile:170) at app//dac.run(SourceFile:41) at java.base@11.0.1/java.lang.Thread.run(Thread.java:834) Narrator: at java.base@11.0.1/java.lang.Thread.sleep(Native Method) at app//com.mojang.text2speech.NarratorLinux$NarratorThread.run(NarratorLinux.java:56) at java.base@11.0.1/java.lang.Thread.run(Thread.java:834) Chunk Batcher 4: at java.base@11.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@11.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@11.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) at java.base@11.0.1/java.util.concurrent.PriorityBlockingQueue.take(PriorityBlockingQueue.java:547) at app//dab.d(SourceFile:170) at app//dac.run(SourceFile:41) at java.base@11.0.1/java.lang.Thread.run(Thread.java:834) ForkJoinPool.commonPool-worker-11: at java.base@11.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@11.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@11.0.1/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1628) at java.base@11.0.1/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177) Signal Dispatcher: at WorldGen-Worker-1: at java.base/java.lang.Thread.getStackTrace(Thread.java:1606) at boo.a(SourceFile:40) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177) at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1603) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578) at boo.b(SourceFile:41) at boo.a(SourceFile:109) at boi.a(SourceFile:44) at bop.a(SourceFile:181) at bpt.d(SourceFile:121) at bnw.c(SourceFile:145) at boa.a(SourceFile:119) at boa.i(SourceFile:37) at boa.a(SourceFile:200) at ty.a(SourceFile:457) at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072) at java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479) at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020) at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656) at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594) at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177) Netty Server IO #0: at java.base@11.0.1/sun.nio.ch.EPoll.wait(Native Method) at java.base@11.0.1/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120) at java.base@11.0.1/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124) at java.base@11.0.1/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:136) at app//io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:756) at app//io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:411) at app//io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:884) at java.base@11.0.1/java.lang.Thread.run(Thread.java:834) Snooper Timer: at java.base@11.0.1/java.lang.Object.wait(Native Method) at java.base@11.0.1/java.lang.Object.wait(Object.java:328) at java.base@11.0.1/java.util.TimerThread.mainLoop(Timer.java:527) at java.base@11.0.1/java.util.TimerThread.run(Timer.java:506) Client thread: at app//it.unimi.dsi.fastutil.longs.Long2ObjectFunctions$SynchronizedFunction.get(Long2ObjectFunctions.java:241) at app//cuv.b(SourceFile:64) at app//cuv.a(SourceFile:29) at app//aza.a(SourceFile:260) at app//aza.c(SourceFile:255) at app//daf.a(SourceFile:81) at app//daf.b(SourceFile:93) at app//cxu.a(SourceFile:914) at app//cxq.b(SourceFile:944) at app//cxq.a(SourceFile:878) at app//cxq.a(SourceFile:752) at app//cjk.c(SourceFile:817) at app//cjk.a(SourceFile:380) at app//net.minecraft.client.main.Main.main(SourceFile:144) Chunk Batcher 0: at java.base@11.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@11.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@11.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) at java.base@11.0.1/java.util.concurrent.PriorityBlockingQueue.take(PriorityBlockingQueue.java:547) at app//dab.d(SourceFile:170) at app//dac.run(SourceFile:41) at java.base@11.0.1/java.lang.Thread.run(Thread.java:834) Common-Cleaner: at java.base@11.0.1/java.lang.Object.wait(Native Method) at java.base@11.0.1/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:155) at java.base@11.0.1/jdk.internal.ref.CleanerImpl.run(CleanerImpl.java:148) at java.base@11.0.1/java.lang.Thread.run(Thread.java:834) at java.base@11.0.1/jdk.internal.misc.InnocuousThread.run(InnocuousThread.java:134) Chunk Batcher 6: at java.base@11.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@11.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@11.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) at java.base@11.0.1/java.util.concurrent.PriorityBlockingQueue.take(PriorityBlockingQueue.java:547) at app//dab.d(SourceFile:170) at app//dac.run(SourceFile:41) at java.base@11.0.1/java.lang.Thread.run(Thread.java:834) Stacktrace: at boo.b(SourceFile:42) at boo.a(SourceFile:109) at boi.a(SourceFile:44) at bop.a(SourceFile:181) at bpt.d(SourceFile:121) at bnw.c(SourceFile:145) at boa.a(SourceFile:119) at boa.i(SourceFile:37) at boa.a(SourceFile:200) -- Chunk to be generated -- Details: Location: 41,-63 Position hash: -270582939607 Generator: bpt@14988aad Stacktrace: at ty.a(SourceFile:457) at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072) at java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479) -- Affected level -- Details: Level name: Qiba All players: 1 total; [ub['Xakep_SDK'/298, l='Qiba', x=-326.26, y=112.89, z=-555.76]] Chunk stats: ServerChunkCache: 8339 Level seed: 1112656407260418052 Level generator: ID 00 - default, ver 1. Features enabled: true Level generator options: {} Level spawn location: World: (240,70,48), Chunk: (at 0,4,0 in 15,3; contains blocks 240,0,48 to 255,255,63), Region: (0,0; contains chunks 0,0 to 31,31, blocks 0,0,0 to 511,255,511) Level time: 19275 game time, 30325 day time Level dimension: 0 Level storage version: 0x04ABD - Anvil Level weather: Rain time: 105279 (now: false), thunder time: 13975 (now: false) Level game mode: Game mode: creative (ID 1). Hardcore: false. Cheats: true Stacktrace: at net.minecraft.server.MinecraftServer.b(SourceFile:733) at net.minecraft.server.MinecraftServer.a(SourceFile:664) at djq.a(SourceFile:125) at net.minecraft.server.MinecraftServer.run(SourceFile:568) at java.base/java.lang.Thread.run(Thread.java:834) -- System Details -- Details: Minecraft Version: 18w43c Operating System: Linux (amd64) version 4.18.16-arch1-1-ARCH Java Version: 11.0.1, Oracle Corporation Java VM Version: OpenJDK 64-Bit Server VM (mixed mode), Oracle Corporation Memory: 701881928 bytes (669 MB) / 4294967296 bytes (4096 MB) up to 8589934592 bytes (8192 MB) JVM Flags: 2 total; -Xmx8G -Xms4G Profiler Position: N/A (disabled) Player Count: 1 / 8; [ub['Xakep_SDK'/298, l='Qiba', x=-326.26, y=112.89, z=-555.76]] Data Packs: vanilla Type: Integrated Server (map_client.txt) Is Modded: Probably not. Jar signature remains and both client + server brands are untouched.
I came across this while attempting to recreate a regression of MC-132073 (that I also accidentally found while recreating something else...). Contrary to the description, the world loads... it just doesn't render. Mobs will still attack you, you can still be pushed into pressure plates (and trigger them!), block break animations from sheep still fire, etc. You can interact with the world, just not really to a full extent.
MC-132073, rather. Update your Java.


It looks like something's broken in world generation.
I created two new worlds in SinglePlayer.
In both cases MC stops running somewhere during loading the save game. {screenshots: taskmgr, loading screen}
Loading (a copy of) a save created in pre3 works OK.
However, joining servers still function correctly, i ran a test on it.
Exactly the same issue for me too, when creating a new world.
Duplicate of
MC-132069unless it is not reopened.Happens to me as well. Odd.
Edit: ...and why do the most important things always break? How did they not notice this major bug sooner? Oh well. Back to 12.2 for now.
Also happens to me. But also, I was unable to load a fresh world created today in 1.12.2. Didn't have any worlds created in the other pre-releases or snapshots to test (I always delete worlds made in snapshots when a new snapshot comes out.)
How many times has Mojang broke the game so far? Just wondering.
The crash log states that an IllegalStateException occurred. Could this be useful somehow?
Was able to create a world in 1.13 pre-release 3 and load it in 1.13 pre-release 4 without issues.
Indeed, opening a 1.13-pre3 world in 1.13-pre4 works fine (and opening that converted world later works, too), while creating a new 1.13-pre4 world freezes at "Loading world". Opening a 1.12.2 world freezes at "Prepare spawn area 1%".
Can confirm. I can't create a new world in 1.13-pre4.
Also unable to load worlds generated in 1.12.2
Stuck at the "Loading World" screen.
Also worth noting that world generation has slowed down considerably since earlier snapshots.
At least we can create superflat world
Confirmed (At least for singleplayer) - Creating a world in pre4 does not work. Opening a created pre3 world does work well.
Same problem for me, singleplayer survival world does not load. (Minecraft version 1.13 pre4) But any pre3 world will load perfectly.
this is happening for windows 7(64bit)/java 1.8.0-171 b11 home as well
Same issue, with the same error pre4. Will test a superflat world
However my world does not load at all. It just crashes over and over.
Edit: After 4 consecutive attempts at loading the same world, it has started to actually prepare spawn area before crashing, causing the game to freeze and require task manager to terminate the process.
*Edit: Successfully loaded world. Though there was a very strange, loud sound made by the game as I joined the world. Sounds like I'm listening to someone on the phone while they are in a tunnel with a train.
The lag is still there just like previous snapshots. Possibly even worse than before.
Please edit / comment with care, it sends an email update to everyone each time you do so.
Same issue when trying to create a new 1.13 Pre4 singleplayer game. I am running Windows 10.
Can confirm in 1.13-pre5.
However, when the integrated server crashes the client closes too (part of working on a fix?). Anyway, my crash report seemed to have more information attached to it so I posted it to the image.
appear to be fixed in 1.13-pre5 ,you can now create default world and large biomes
Matthew, Pierrot Charles:
Hm.
Works for me in pre5
Look at the crash report I posted from pre5. It still happens for me (although admittedly not every time–at the time I wrote the comment it was the first time I attempted generating a new world), not to mention that it wasn't marked as 'fixed' yet by Mojang.
We have two computers each with their own Minecraft account. One is able to start a new world as of today but the other is not. Both had the same problem as described yesterday and both are now on Pre5. One of them can create a world now but the other appears to still have the same problem. I'm currently in the middle of formatting the other PC with a fresh windows install (unrelated) and we'll see if it continues to have problems.
Just figured it out–this is a Java related issue. Running 1.8.0_25 (which was the version I ran in the first crash that came from the launcher) caused it to crash the game. Running an updated version which I got since then gave me no issues.
Sorry for any confusion.
EDIT: Dinnerbone on Twitter
EDIT 2: I'm pretty sure today's update to the launcher changed the built-in Java version (1.8.0_51), and fixed the issue for me..
Fixed with Launcher versions 2.1.1216 / 2.1.1217 / 2.1.1218 and the updated bundled JRE 1.8.0_51
The crash is still present in 18w43c, just occured a few times while generating chunks in a new singleplayer world. Not sure how to reproduce it consistently yet.
crash-2018-10-26_13.10.32-server.txt
crash-2018-10-26_13.13.56-server.txt
OS: Windows 10 1803 (Build 17134.112)
Java: Bundled JRE (1.8.0_51)
JVM Arguments: Default + -Xms4G -Xmx4G
I have been having the issue in 18w43c as well. So far, all I've done in the version is fly around the world a lot, but the world continually fails to load in, freezing and loading a few chunks, then freezing and loading a few more, and every once in a while freezing and then loading in everything around me as expected. It continues this cycle regularly until eventually, around the time when I'd expect the world to load everything normally, the entire game simply crashes.
crash-2018-10-26_13.13.56-server.txt
Edit: I tried running in Java 11 as well just to see if that would fix anything, but it didn't.
This crash is still present in 18w44a. I just experienced it on the first launch of a 1.13.1 world in 18w44a within minutes of the world version upgrade. I have attached my crash report (crash-2018-11-04_16.24.34-server.txt
) that was generated after the crash. The crash occurred when I died and attempted to load the spawn chunks at a custom location set a couple thousand blocks from spawn- the world refused to render and within 30 seconds the game crashed. I have tried for hours to reproduce this crash, to no avail.
The crash report in 18w44a is identical to the ones posted by VideoklipBG (crash-2018-10-26_13.10.32-server.txt
and crash-2018-10-26_13.13.56-server.txt
). Although the file names are different, this is because of the obfuscation between versions since the line numbers match up perfectly. The line numbers in mine are all off a bit from the original crash reports.
The only thing that caught my eye when I was comparing the crash reports here was that mine referenced datafixer in one of the last few lines in the stacktrace. This led me to think that this was caused (and thus reproducible) by converting another 1.13.1 world. This does not seem to be the case at the moment.