Jump to content

Block ID mapping was destroyed -- world corrupted.


keybounce

Recommended Posts

This happened with Forge 1208. I am aware that this is not latest. This is not repeatable reliably -- I have run this same setup many times without problems, and do not know why it decided to die on me now. EDIT: Potentially, the crash happened in single player when the client ran out of memory.

 

Again: My block/item ID mapping was wiped. All ID numbers in the region files were claimed by a different block, so anything not vanilla became something else. Opening a chest resulted in a client D/C. Restoring a copy of level.dat from a backup did recover blocks properly (* but NOT their orientations *) in the overworld and most ages, but the most recently used mystcraft age had horrific wrong blocks.

 

This is sufficiently catastrophic (loss of ID map destroying everything) that I felt it should be reported even though it's not latest.

 

Logs:

 

First, starting up the world in SMP mode. No problems -- everything worked just fine.

 

https://gist.github.com/keybounce/b77dc5f2f2cf893fb694

 

Then, I realized that I was planning on doing long-term chunk profiling -- and trying to run my client by itself will result in a random d/c after somewhere from 30 minutes to 2 hours. (This happens when minecraft falls 25-30 seconds or more behind, and skips ticks to catch up -- the client complains, D/C's, and on reconnect the player's position is far, far away from any place the minimapper remembers getting data for from the server. I don't think this is a forge error; I think this is just chunk generation slowness.)

 

So, I stopped the server, and restarted in single player. Startup was no problem. Logs:

 

https://gist.github.com/keybounce/8525a6c45859329fb3ea

 

Again, at this point, no problem.

 

So now, I start up again, set flight mode, fly off in a diagonal, and plan to come back in the morning with many hundreds of thousands of chunks profiled overnight while I slept.

 

After about 30 minutes, the client ran out of memory, and shut down.

 

https://gist.github.com/keybounce/f448ecb8e9494ee80e36

 

The crash happened at 1 am. level.dat from that timestamp has a broken set of ID mappings in it.

level.dat from 11:58 pm the previous day has proper ID mappings.

(no copy between those two timestamps is available)

 

... reviewing that log, I had been under manual control until about 12:40 am, put it on auto-pilot at that point, and it ran out of memory 20 minutes later.

 

Again: At this point, the level.dat saved and in Time Machine shows a broken set of block ID mappings, while the one from the previous night just before midnight has a good set of block ID mappings.

 

World sharing: The client has a symbolic link from the save directory into the server's directory. Other than getting a different inventory/location when logging in single player than server, everything works fine in both setups.

 

Jeb! The sheep! The fence pens, they do nothing still leak!

Link to comment
Share on other sites

If you are aware that 1208 is not the latest, then why do you not use the latest?

 

If you want to do funny things in an arcane way and forge breaks because of it, then we can't help you.

Read the EAQ before posting! OR ELSE!

 

This isn't building better software, its trying to grab a place in the commit list of a highly visible github project.

 

www.forgeessentials.com

 

Don't PM me, I don't check this account unless I have to.

Link to comment
Share on other sites

The level.dat is backed up before writing for this exact reason, erroring while writing.

Use the backup.

There isn't anything we can do about stuff like this.

The world isn't 'destroyed' it simply has different mappings.

 

My suggestion, stop doing things that kill your memory.

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.