So I can get the world file for you but it's kind of big and you need a computer with serious ram for it not to go bananas but it still kinda does on mine.
So thanks to a ton of patience and task manager I was able to meticulously map out the chunk radius that was causing me grief. There is an outside stone circle ring. If I go inside that stone ring for even one second my RAM shoots to 14+ GB often much higher. It usually settles down after awhile until I leave the area and come back to the ring which was the painful process I had to follow to map this out.
When I finally turned up my render distance I noticed that there was those couple of chunks that appear to be in the middle of the ring that seem to have an extraordinarily difficult time loading. I'm wondering if this is maybe a chunk error issue and is causing the game to absolutely lose it's mind. It's out of my simulation distance and render distance when I turn it down but no matter what when I cross the stone circle my RAM shoots. It's symmetry definitely hints to me that something in there is causing the hiccup. I tried to get the world in UME but it throws a fit and crashes.
Please if you have any information let me know the world has been crippled for awhile and I finally had the time to go through and monitor where my ram kept freaking out.
On a side note I'm kind of impressed that I managed to trace out the problem area
Attachments
Comments
migrated
migrated
So do I need to repost this to MCPE-85614?
The world is having issues and I worked very hard and diligently to trace the problems. These chunks don't contain a lot and is causing the ram to shoot up to 16 GB+
So should I just copy and paste this over to that report?
migrated
Yeah. Best thing to do.
Auldrick
I am reopening this and removing the "duplicates" link because I don't believe this is the same issue; the other ticket is about slow chunk generation and/or loading, but once they load they're normal chunks. Yours isn't like that, and I think you're 100% right that you have one or more corrupted chunks. You've done an excellent job of finding the evidence for that. Thank you for the diligent work, it's appreciated!
Unfortunately, corrupted chunks generally can't be repaired, though you might be able to mitigate the damage. The bug that caused the damage (if it even was a bug; it could have been a cosmic ray!) is theoretically fixable, but the information we would need to do that is lost to history. So I've probably reopened this ticket only to have to close it with the resolution Can't Reproduce. Unless we're able to reproduce a bug, or at least describe it precisely enough to identify what part of the code triggers it, the developers can't fix it.
But I can at least suggest some things that might help. First, the bad chunk is almost certainly the one in the center of your circle. The circle's size is probably a function of either the render distance or the simulation distance. You could try varying those (in a copy!) to see if either changes the size of the problem area. If so, you might consider doing one of the following:
Play the world at the smaller distance setting(s). This is probably the safest way to proceed, since it doesn't risk compounding the damage that has already happened.
Move any builds and resources you want to keep out of the chunks you've regained access to, then try to delete the chunk. (Note: Mojang does not recommend using a third party editor to delete chunks, so you do this at your own risk.) This would let you resume playing at the original settings, but you would need to stay outside the circle.
Although UME was unable to access the chunk, it might be still be able to open the world, and if so it might let you delete the chunk. It's more likely to succeed if you don't do anything that would try to display the contents of the chunk, either by expanding the hierarchical list item for the chunk or scrolling to it in the map. You would need to calculate the chunk coordinates, then use the branch names in the list to find and delete it. If UME can't do this, you might want to try MCC Toolchest PE. (Note that the latter requires you to calculate the region coordinates as well as the chunk coordinates. I'm not actually sure how to do that.)
Something else that might be worth a try is to make a copy of the world using the game's Copy World button. I think this function checks for and repairs some kinds of data corruption as it builds the copy.
As I said above, I expect to close this report as Cannot Reproduce, but I'm going to wait a little while before I do that, in case you have additional information. For example, if you find a way to reproduce this, even if it's in a different world (but with similar symptoms like 16 GB chunks), we could still pass it to the devs.
Auldrick
@unknown: I know you just want to be helpful, but please remember that the bug tracker is not a community forum or support site. There are better places for that, such as the Minecraft Discord. The staff here may interact with a bug reporter in a similar way while we're trying to get enough information to forward the bug to the devs, or (as in this case) to offer alternative help when a bug report can't be forwarded, but if we let everybody in the community use it that way, there would be so many of those comments that it would be very hard to separate the bug information from the rest. Thanks for your understanding.
migrated
So I managed to delete the center chunks in MC Tool Chest and my world went from pushing 5GB normally and spiking to 16GB when I enter the problem area down to 500MB everywhere. Idk what was so bad in those chunks but wow it healed the world to delete it!
Auldrick
Glad to hear that!
Since you're interested, I'll mention that bugs that eat up unlimited amounts of memory are typically caused by improper self-references in the data that causes the program to enter an infinite loop in which it allocates memory for more data, again and again. An example might be a shulker box that somehow gets stored as an item inside itself, or a hopper that incorrectly thinks it's underneath itself so it sucks its own inventory into its inventory.
I'm now closing this ticket as Can't Reproduce, since you've resolved the issue as much as we can expect to.
migrated
@@unknown Sorry. I am having a few issues lets say so i am doing stuff a bit wrong. I will try to improve.
migrated
That is interesting. I have a question because I may know what caused the issue in the first place. Someone ran the command in a RCB at one point
/execute @e[type=egg] ~~~ summon egg
would that have caused the infinite loop you were talking about?
On a final note the world did actually eventually load. It just took a good 5-15 minutes to load that chunk area on my machine. It would crash most consoles. I wanted to make sure that information didn't get lost
Auldrick
I can't say for certain, but it's plausible—maybe even likely—that that command would have such an effect. Whether it really does depends on whether the /execute command make a list of all eggs first, then executes the command for each one, or finds one egg, executes the command for it, and goes in search of another egg until it can't find any more. Either would work, but only the second would cause an infinite loop. But if I were designing the command logic for Minecraft, I'd use the second method because it's a multiplayer game. That means another player might do something to introduce an egg while the command is running, and if the /execute command made a list first, it wouldn't see the new egg occurring later. So I'm very much inclined to believe this is what happened.
(In fact, it's because I hoped I might jar your memory this way that I took the time to explain it the way I did. And you walked right into my trap! Mwahahaha! j/k)
I'm delighted that you finally did get your world back. How did you stop the loop? /kill @e[type=item]? (Be careful: That will eliminate all types of floating items within your simulation distance, not just the eggs.)