mojira.dev
MC-130162

Exception generating new chunk - OutOfMemoryError: Java heap space (32 bit Java)

When the game is paused at the main menu and it is generating chunks, it runs out of heap space.

Load the attached save game (T1_18w21a).

When the game loads, press F3 (to show memory) and then Escape to pause the game. (This step is optional)

The game will crash after a few seconds when it exhausts memory.

(The save game is in three parts - part 1 has most of the game files and a few region files, and parts 2 and 3 have most of the region files.)

escription: Exception generating new chunk

java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: Java heap space
	at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2237)
	at sj.c(SourceFile:129)
	at sr.a(SourceFile:84)
	at ss.c(SourceFile:143)
	at sk.i_(SourceFile:223)
	at net.minecraft.server.MinecraftServer.w(SourceFile:694)
	at net.minecraft.server.MinecraftServer.v(SourceFile:627)
	at dii.v(SourceFile:156)
	at net.minecraft.server.MinecraftServer.run(SourceFile:532)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.OutOfMemoryError: Java heap space
	at it.unimi.dsi.fastutil.ints.IntArrayFIFOQueue.resize(IntArrayFIFOQueue.java:175)
	at it.unimi.dsi.fastutil.ints.IntArrayFIFOQueue.expand(IntArrayFIFOQueue.java:189)
	at it.unimi.dsi.fastutil.ints.IntArrayFIFOQueue.enqueue(IntArrayFIFOQueue.java:201)
	at cbm.a(SourceFile:142)
	at cbm.a(SourceFile:146)
	at cbm.a(SourceFile:130)
	at cbp.a(SourceFile:62)
	at tb.a(SourceFile:23)
	at sx.a(SourceFile:34)
	at bqc.a(SourceFile:87)
	at td.a(SourceFile:59)
	at td.a(SourceFile:23)
	at agg$a.a(SourceFile:143)
	at agg$a$$Lambda$1526/136461969.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)

World download from MC-131617: http://www.mediafire.com/file/3n2y3fqye7obqnz/Jungle_Home%252C_Where_are_You%2521.zip/file

  • The world does not initially crash, but will after generating new chunks

Related issues

Attachments

Comments

migrated
[media][media][media][media][media][media][media][media][media][media]
bdm68

The attached save file (T1_18w21a) was generated by flying in a straight line until the Worldgen worker threads crashed, as described in MC-128163. When this game was reloaded, this crash happens.

 

AceMcCrank

I'm including a log as well, because even though I did get the crash, it was while I was not moving in my world, and had been fairly still for several minutes.

AceMcCrank

And, I found a way to replicate it, despite setting my RAM settings up to 4 GB - I simply set a block on fire. You can actually see the memory get really high really quickly as soon as I set it on fire. I've uploaded video evidence here: https://youtu.be/9GFpfP0YGtY
Initial crash in the first 15 seconds, I then reload at about the 30 second mark, and get the game to crash again at about the two minute mark.

I have a Quad-core i5 @ 3.2 Ghz, 12 GB RAM, and an ASUS 550ti.

kumasasa

Does MC-129492 describe this issue ?

bdm68

I don't think MC-129492 describes the issue accurately. I can reproduce the issue quite quickly using the attached save file without moving. I created another world with the same seed and stayed in one place. The crash did not happen.

As far as I can tell, the attached save file has incomplete chunks caused by MC-128163. When that world is loaded, the game tries to complete the chunks and it runs out of memory, even when the game is paused.

bdm68

I have investigated further, and there is definitely a problem with the chunk Status in the attached save, T1_18w21a (caused by a crash). So far as I can tell, the chunk status normally goes in the sequence empty, carved, liquid_carved, decorated, lighted, fullchunk, postprocessed. In a normal save file, chunks with these statuses will form distinctive rings with chunks in the innermost ring having the "postprocessed" status, and each concentric ring outwards will be one further back in the sequence. In the T1_18w21a save, the rings are broken.

This is best explained by pictures (empty = red, carved = orange, liquid_carved = yellow, decorated = green, lighted = blue, fullchunk = purple, postprocessed=white). The pictures were generated by extracting the status for each chunk and colouring them according to that scheme.

bdm68

The difference between this issue and MC-129492:

MC-129492 will occur slowly over time until the server crashes. The player must actively generate chunks by moving.

MC-130162 will occur quickly if the world is reloaded (usually within 60 seconds) when there are incomplete chunks in the vicinity. It can occur after a crash due to MC-129492 or other causes but won't usually occur first. The player need not do anything after reloading the world.

bdm68

Server and launcher logs attached.

migrated

I am getting this error on 1.13 pre 2 and the report I submitted has been called a duplicate and claims to have been solved yet I have zero idea what's happening or how to fix it.

kumasasa

@unknown, bot resolved to default "User has assigned 256 MB to Minecraft and got OOM" ticket, fixed that.

bdm68

Attached another Status Map (as "Status Map.png") showing the value of the "Status" variable in the affected chunks. This one was generated in a 1.12.2 world being loaded in 1.13 pre2 after experiencing the MC-129492 SP server crash.

The position of the player is marked with "x". Chunks adjacent to the player did not have a "postprocessed" status and these chunks did not render in game.

It shows another example of the status flags for adjacent chunks are not in the expected sequence. It looks as if the chunk generation and conversion doesn't handle it well when the status sequence is not what it expects.

Status Key:

  • empty = red

  • carved = orange

  • liquid_carved = yellow

  • decorated = green

  • lighted = blue

  • fullchunk = purple

  • postprocessed=white

  • mob_spawned = brown

  • unconverted 1.12.2 chunks = grey

Chunks in proper sequence would appear as a rainbow with a white middle.

bdm68

I also want to share an observation that may be related. The chunk at 0,0 has a "fullchunk" (purple) status even though that chunk has not actually been loaded in game. I have logged this as MC-131604.

 

Asteraoth

Is this still an issue in Minecraft 1.13.1?

bdm68

(Unassigned)

Confirmed

Minecraft 18w21a, Minecraft 1.13-pre2

Retrieved