Moving through world gradually uses up all memory, causes stuttering and crash

Although it would still be an issue deserving attention, for you to allocate 2 GB of RAM to minecraft, I'd bet it'd hide itself. This is my new and first account, so I hope I don't forget about this site and comment.

I did try that and forgot to mention it. Allocating more RAM does not remedy the issue significantly. An extra GB of RAM only gives me about 700 additional blocks before the issue occurs again. I'll update the description to reflect this information. Thanks for the reminder!

By the way, if you click the "Watch this issue" link near the top of the page, you'll get email notifications to remind you of any activity on this ticket 🙂

I'm having the same problem. The longer I fly around the more the game stutters and then eventually it crashes. The first 18w19b game I played in this seed crashed and now won't open again.

seed: -8300275442758179407

Just crashed again. And all I did since posting the above comment is fly around exploring. In previous snapshots I went out as far as 5000 x 5000 with no problems and nothing about my system has changed.

The grayed pic is when the game crashed. It just froze then the game shut off. The other pic is a shot of when I opened the game again.

I'm on Windows 10, PC.

Updated with information from testing performed on Windows 10 and attached a game output log screen capture showing warnings in console output.

@Jen Ivins

Thanks for confirming. I should mention that in the test world that I attached to the bug, I was also not able to load it again at first after saving – it immediately crashed the game, but did eventually load after closing and restarting completely.

@kiddailey Yes! That happened to me too. If the world starts to get laggy and I exit the game and give it a minute it seems fine again for awhile.

Also confirmed for 18w20a. Still having the same issues.

I'm noticing it stutters more as more mobs are loaded in an area. Could it have to do with mob generation rather than world size?

I've updated the affected versions after having also confirmed myself that this issue persists in 18w20a.

@Jen: Mobs may be contributing, but I think there's something at a deeper level that's the primary issue. If you look at my notes in the bug above I mention that it also happens in a void world. Void worlds have no spawning surfaces, no mobs and no blocks beyond the initial small square of blocks that you spawn on. If it's the mob spawning code, it's something that happens when they're not actually in-world.

If I had to guess, I'd say that the issue is probably related to chunk loading/unloading. If that's the case, it may not even require a large world to trigger the issue. You could simply fly around in a large enough circle so that chunk loading/unloading is actively occurring.

That actually may be an interesting test to perform. If I get a chance, I'll give it a whirl 😉

I decided to try the test immediately with 1GB allocated first. 😃

Starting at 0, 0 on a newly generated world, I flew in a large square pattern around approximately an 50x50chunks/800x800 blocks sized area (within -400,-400 to 400, 400). Within one loop I had already started hitting the stuttering point. Going to do some more testing and eventually will add it to the description, but it seems my hunch about it happening just by traveling in circles is correct.

It also occurs with a 2GB allocation, though (unsurprisingly), it takes longer to hit the stuttering point. So, that appears to confirm that world size isn't the issue.

It is also likely that we may be able to create a test world using a minecart and rails where the player simply travels back and forth, loading and unloading chunks. I'll create a void world with a track for testing to see if it works – it'd sure make testing easier and will eliminate a bunch of other testing variables (blocks, mobs, etc). I'll attach it if I can when it's done.

This may be just coincidence, but it seems like the "Can't keep up!" output warnings I posted a screenshot of may be directly related to the memory usage increases. In other words, when the server reports that it can't keep up, it's failing to release memory that it would otherwise release.

From my testing if you use the /locate command and the nearest structure is far away, the game will say that no structure can be found (from my testing 1.12.2 can find structures significantly farther than it can in 18w20c). If you then proceed to fly in any direction, the game will crash due to this bug much faster. 

@Timothy Yes! I noticed that too! But I'd not used the locate command before now, so I wasn't sure how far away it should find things. And it definitely makes the game crash faster.

Regular exploration on a survival map is enough to cause the game to be unplayable due to this, requiring a restart- this bug is not just in creative mode.

@unknown, maybe 1G of memory is too less since it's used up, assign more RAM and try again

@Kumasasa - I've tested with various allocations of RAM and it still occurs, though it takes longer to reach the limit the more memory you allocation. I originally noted in the issue description that I tested with both 1GB and 2GB allocated, but in all cases I've tested, the game will eventually use all allocated RAM and begin to have problems.

Confirmed, I flew through a world and generated new chunks; the game used up about twice as much memory than it did in a world with the same seed in 1.12.2.

Updated to include that this impacts the latest snapshot - 18w21a

Anyone who is impacted by this issue should also review MC-128163, which reports a very similar memory leak that impacts the Worldgen worker threads and saving the game. The most severe consequence of that bug is that once the Worldgen worker threads crash, saving the game is no longer possible. When you have exhausted RAM as a consequence of MC-129492, you are also affected by MC-128163 if you press Escape and press "Save and Quit to Title" and the game does nothing. If you are affected, please vote for that issue.

Right, so in 18w21a the game is just crashing and closing completely. It did it when I started for the first time. It did it after I went less than 50 block from where I spawned. It did it after I teleported to 2 different places. Whatever was happening before, it is now much worse.

seed: -8300275442758179407

As a general observation, I would agree with Jen - this latest snapshot seems to suffer from this issue moreso than the previous. Additionally, the requirement of moving through the world appears less important.

I started a new world in 18w21a, spent an hour or so fiddling around with basic game start actions in the same general area (less than 1 region/32 chunks) and had to shut down and restart the game a couple of times to resolve the memory issue/sever frame drops.

I did perform some quick branch mining which may have generated a few chunks, but nothing as significant as my original tests posted above.

Similar to others in this thread, I started a creative world in 18w21a and was flying around generating chunks and exploring the huge amount of shipwrecks for fun. And as I explored, I started getting bad frames every few seconds, opened F3 and it was memory usage at 98%, world stops responding. Cannot save or quit. So I exit Java using task manager. Now whenever I open that world, after a couple seconds it crashes and gives me a crash report.

@unknown: According to your crash report, this is MC-130162

Updating to confirm this issue persists in 18w22b and 18w22c

affect 1.13-pre1

affect 1.13pre-2

Have not managed to repro yet. No matter how much/far I sprint-fly the system always manages to GC down to <400Mb

It happened to me when I kept flying through a default world for a while, my game kept freezing for half a second and I saw that the ram usage was very high in the f3 menu. I reproduced the issue with minecrafts default 1GB ram allocation.

@Rikard: I've performed a few tests with 1.13pre-2 1GB and can concur that I'm also seeing garbage collection dropping usage down to around 50%. Allocation still remains at 100%, which is expected. I am seeing a significant "freeze" when the GC happens, but that is not surprising and the game does recover and remains playable.

I tested with a few different worlds, including a buffet warm ocean world with max render distance (the most problematic for me in the past) and see the same results.

The original bug as I reported was that the GC never cleared enough RAM causing the game to become unplayable and sometimes crashing, so it may be that this issue has been resolved.

Things indeed seem to have improved; when I reproduced the issue, the allocated RAM easily reached 100%. When I just tested it again in 1.13-pre2, I was no longer able to reproduce this particular performance issue.

I have spent over an hour moving around an old world generating new chunks and converting existing chunks. Ram allocation was at 96% when the world loaded (2GB max) and it did not change over the course of four in-game days. Actual RAM usage was in the range 50%-60% for much of the time. I could not reproduce this issue in pre2. When I tried the same thing in pre1, it crashed after about 20 minutes or so.

I spent some time with 1.13pre-3 (1GB alloc) today with a few different seeds and it seems to have degraded a little. As I mentioned above with pre-2, I was getting 50% back after GC and it would take some time to reach 100% used again.

WIth pre-3, I'm only getting 35-40% back and usage climbs back up to 100% much more rapidly than with pre-2. Can anyone else confirm?

The issue seems to be back in pre3.

I generated chunks using a command block chunk generator that teleports the player around the map at intervals. After a while, chunk generation halts and the game cannot be saved. From the symptoms, it is difficult to determine whether it is caused by this bug, MC-130162 or another similar issue.

I can't seem to reproduce this bug in pre3 with 8GB allocated on default worlds.

I did however manage to reproduce this in an amplified world but it only very slowly climbs up to 100% so I think Kiddailey's comment is true.

still affect 1.13-pre3

Which launcher and jvm arguments are you using ?

Seems like the problem is related to specific java arguments.

Well i'm using Xmx-8G but if I use 1G, the problem is more noticeable.

May be fixed in 1.13-pre5, see this comment

Reproduced in 1.13-pre5 after generating chunks for about 2 hours with 2Gb RAM.

Some tests with 1.13-pre5. Could be more thorough, but I've got limited time at the moment. Hopefully it's useful.

The TLDR is – It definitely is better than it was in my original report/tests and mostly fine if players set their render distance more conservatively than they have in the past. But 1.12.2 sets the bar pretty high – I can't recall ever seeing a GC lag spike regardless of my render distance. The data below also seems to hint that there may be patterns or commonality between when the spikes happen.

Edit: Threw in a super-flat world with surprising results. Really feels like a chunk load/unload issue and that it may have been mitigated partially somehow but not really fixed 😞

—

Global Testing Parameters

• Same environment as original bug report

• 1GB allocated (default, not set with params)

• Exit game completely between each test

• Newly generated, default, creative world

• Using seed from original bug report (-9218963885634162416)

• After spawn, fly up to Y 125 and fly due-south (going up/down as needed)

• Go through at least three Garbage Collection lag spikes

• Note spikes as "Blocks traveled before spike (RAM usage% after GC)", secondary spikes are cumulative

Group 1 - Test Specific Parameters

• 32 chunk render distance (pushing the envelope of 1GB 🙂

• Sprint flying

Note that on test #5, my keyboard batteries died before the first spike and while I swapped them I could see the chunk rendering catching up to me and loading the full 32 chunks. The game was unplayable when I went to resume testing. In all my comments/test before, I've been sprint flying (as I did in the sample video posted with the report), but based on my experience with that test I thought I'd also perform a walk-flying test instead (where more chunks would be loading/unloading as I was moving). The results with walk flying were unsurprising:

Group 2 - Test Specific Parameters

• 32 Chunk render distance

• Walk flying

And lastly, I performed a test with rendering distance set to 16 chunks for comparison:

Group 3 - Test Specific Parameters

• 16 Chunk render distance

• Walk flying

Edit:

I wanted to do a quick test with a superflat world and was surprised:

Group 4 - Test Specific Paramaters

• 32 Chunk rendering distance

• Superflat (default)

• Sprint flying

• Seed: -3561884775657408351

Is there a bug that may be related to this just for generation of decorations? Or perhaps it is partially something to do with rendering transparency? Because I can start a buffet world at 32 render distance with the biome "Dark Forest" and without even moving it will induce lag spikes from GC which eventually make the game unplayable.

Wow. That's an interesting find, and I can confirm I have the same experience. Just did a test in a Dark Forest Buffet world (seed: 1844439826410695340), creative mode, 1GB, 32 chunks and did not move at all after joining the world.

1 minute and 52 seconds in, the game had allocated 100% of the RAM. I saw my first (of many) lag spike 51 seconds later. I let it sit for a while longer and the game became completely unresponsive. Again, as Tedstar mentioned – without moving around at all.

Edit: It's not as severe, but this happens even in superflat worlds with nothing but the basic ground layers and very little (if any) transparency and decorations.

To make reproduction easier, see MC-130427. That bug report describes an automated method of reproduction that uses a redstone and command block chunk loader built in the spawn chunks.

If you're able to reproduce this please let us know which launcher and jvm arguments you are using.

I could also reproduce this issue with Minecraft 1.13-pre5 running:

Windows 10 (x64, 1709) with 32GB RAM and an i7 6800k processor + AMD RX Vega 64 graphics card (driver: 18.6.1).

Minecraft Launcher: 2.1.1216 (with Java Version 8 Update 51)

JVM arguments: -Xmx2G -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=16M

Everything else in the launcher is at default. View distance was set to 32. For me it took about 20 to 30 thousand blocks for the issue to appear while sprint flying through a newly generated world. I tested it three times and could always reproduce this issue (thought it never crashed for me).

Environments:

Windows 8.1 Pro 64bit, Intel Core i7 16GB RAM, JAVA 1.8.0_25 64bit, NVidia GeForce GTX 770/PIC/SSE2 4.6.0 NVIDIA 391.35
Windows 10, Intel Core i7, 16GB RAM, JAVA 1.8.0_25 64bit, Intel HD Graphics 620, 4.4.0 - Build 21.20.16.4550

Minecraft Launcher:

2.1.1216

JVM Arguments:

Default/none

Please take my report with a grain of salt as I am running Minecraft on a potato. Due to this I had low FPS the whole time anyways, however I still noticed the GC spikes easily due to the F3 statistics freezing and because it created a system-wide noticeable (outside of the game) lag spike. I also observed the memory usage approaching 100 %.

Test: Buffet world with generator type "Surface" and biome "Dark Forest" and structure generation turned off. After world load no movement, but I did look around once in order to trigger the chunks getting loaded.

Minecraft version: 1.13-pre6

Launcher version: 2.1.1216

JVM arguments:

-Xmx1G -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=16M

Results: Loading the world with render distance 16 chunks went fine (tested for several minutes). Allocated memory was at ~ 60 %. Increasing the render distance to 32 chunks quickly allocated 100 % memory and within seconds the used memory approached 100 % and the first lag spike occurred. After this the memory usage was at 70 - 90 % and every minute or so suddenly went towards 100 % with a lag spike occurring. The results are identical for tests performed with low and high graphics settings ("Fancy" graphics, "Maximum" smooth lighting and "4" Mipmap levels vs. "Fast", "OFF" and "OFF").

affect 1.13-pre6

My JVM arguments for my snapshot testing configuration:
-Xmx1024M -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=16M

Limiting memory with the -Xmx1024M argument will cause the issue to be reproduced more quickly. It can be reproduced with -Xmx2G but it takes a lot longer.

My reproduction steps included a chunkloader that teleported the player. It can be reproduced by moving manually, but automation is more convenient. I have attached a chunkloader in the attachment g13.zip. You can use this chunkloader to reproduce this defect if you follow these instructions:

• Place a structure block in the spawn chunks of a new Default map. (I used the seed 1, but any seed should work).

• Unzip the chunkloader as "g13.nbt" in your world save in the folder "generated/minecraft/structures".

• Load the chunkloader "g13".

After doing this, the contraption is ready to use.

To start, stand in mid-air above the oak log on the platform and press the green button. This will start generating chunks by teleporting the player around the map.

Render distance seems to have a fairly large impact on this. Setting a render distance of 13 with 1024M RAM causes RAM exhaustion fairly quickly and latency to reach quite high levels ("Can't keep up! Is the server overloaded?" messages reaching as high as 100,000 ms as RAM reaches close to 100%). It appears that stale chunks are not being released from RAM reliably.

Reducing render distance to 8 with 1024M RAM is much more stable (RAM was not exhausted after 2 hours and performance was still good after travelling 60,000 blocks).

Method used: modified version of the "g13" chunkloader that advances the player by 4 blocks every 0.8 seconds to simulate walking speed, with player teleporting at a height of 96 blocks in spectator mode.

I've been doing some testing with bdm8's "g13" chunk loader structure block (thanks so much for putting that together, bdm8!) in pre-release7/launcher 2.1.1216 with a default, creative mode, same seed as original in report (-9218963885634162416) world and a 32 chunk render distance. The chunk loader simply teleports the user around at a high Y value every few seconds, allowing chunks to load between each teleport.

Nothing too surprising was revealed but thanks to the automation, it allowed me to easily test larger RAM allocations. The TLDR summary is that the issue exists regardless of how much RAM you allocate to the game.

Observations of note:

• It does not appear to matter how much memory you have allocated to the game. It may take longer the more you provide, but eventually the game will allocate and use all RAM and render the game unplayable.

• With less RAM allocation (1-2GB), the game appears to become unstable (frame rate drops) and unplayable (complete stalls/lag) at nearly the same time

• With more RAM allocation (8GB+), the game appears to become unstable before it reaches 100% allocated/used, with occasional drops in frame rates while chunks are loading/unloading and negatively impacting the system overall. For example, in my 8GB allocation tests, the game begins to have regular frame rate drops to 2-5fps at around 80 - 85% RAM allocation, eventually becoming completely unplayable at 100% allocation/usage.

• With 8GB allocated to the game (32chunk render), the game used up all allocated RAM after about 5-6 hours

• With 4GB allocated to the game (32chunk render), the game used up all allocated RAM after about 3-4 hours

• With 4GB allocated in a dark forest buffet world, the game used up all allocated RAM after about 1-2 hours

• Attempting to "Save and Quit" an 8GB allocated instance of the game that has used all 8GB causes the game to become completely unresponsive for 2-5 minutes while it tries to save and return to the main menu.

• To adjust the RAM in my tests, I used the default JVM arguments and only adjusted the -Xmx value, eg. "-Xmx8G -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=16M"

1.13-pre8 should have fixed at least one source of the memory leak, please verify that it still happens for you.

fry, the situation seems to be getting much better for me. RAM usage is down in my testing worlds (not going above 1GB which used to happen frequently)

I've only had time to do some quick tests with 1.13-pre10 and a 32chunk render distance and I've definitely seen improvement with allocations of 4GB or more.   Over an hour into testing 4GB/32chunks and RAM allocation sat completely steady at 71%, which is awesome!!

Any allocation less than that still seems about the same though.  Allocations of 2GB start having issues around 45min and with less RAM, sooner.  I realize that 32 chunks is a bit much for only 1-2GB of RAM, but I keep including these in my tests since it's around the default allocation in the launcher and 1.12 seemed to handle it acceptably.

Good luck to you all with the launch and thanks for all the hard work on this amazing release!

@unknown, is it a new 1.13 world or an upgraded 1.12 world and did you optimize the world?

I'm always generating a fresh, default creative world in the 1.13 versions with seed -9218963885634162416 (same seed as in the original report) for every test, and quitting the game completely between each test. 

Edit: Forgot to mention that I'm using bdm8's "g13" chunk loader (attached to bug report) for the tests.

Can also confirm that this seems to be fixed in 1.13. Flew 5000 blocks loading new chunks, Minecraft never used more than 40-60% of 1GB allocated RAM.

Ok, we consider this issue as fixed.

Yes, this very annoying bug as been fixed 😊

The other day I was helping a friend troubleshoot the game after he just upgraded to 1.13.  It would launch, start and immediately freeze on him when he tried to load a world.  My hunch that the culprit was this bug was correct – the game was immediately using up all allocated RAM and freezing enough that he couldn't play the game.

His install was using the default settings (and a medium render distance), so the game was only being allocated 1GB.  Setting a custom JVM lanch string to allocate 4GB resolved the issue.

As I've mentioned above, I can concur with my own testing that it still is an issue with many (if not most) worlds I've tested in 1.13 with only 1GB allocated and a medium-high render distance and don't think it has been resolved completely.   In any case, it may be that the only remaining fix is to make the launcher allocated 4GB by default instead of 1GB.