Philip Cass
Comments
@JB suggestion: it might help if you were able to upload a world which exhibited this behaviour (and noted the coordinates that trigger it, natch)
The thing is, *because* this is extreme bloat and not a memory leak, you can just power through by just ensuring you give it enough memory. If you know your mineshaft object is going to take 2 gigs, allocate 2 gigs more heap. CPU problem goes away (because it doesn't have to run the GC constantly to keep the server running). The long save times would remain, though. Thanks Mog for acknowledging Poweruser's analysis, it's reassuring to know you're aware of the root cause of these symptoms, even if the solving it is still ongoing.
@Poweruser - see my comment at https://bugs.mojang.com/browse/MC-33134?focusedCommentId=133962&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-133962 - there seems to be something fundamentally odd about how the mineshaft.dat object is stored in memory which is also causing issues
If you do a memory dump *after the server has been running a while to allow places to be explored*, you will notice the object representing the mineshaft.dat file can use several gigabytes of RAM.
16 Megabyte mineshaft.dat file (gzip compressed as most minecraft files are)
= 100 megabyte uncompressed mineshaft.dat file
= over 2 gigabytes in-memory object
What this means for me, with a server with -Xmx2G set, is that the CPU is spiking and the server is lagging because of continual full GC runs because the object is taking up space. This would seem to be the root cause of this bug, as well as a major contributing factor to MC-33086 (though I notice someone is also providing evidence that changing how the file is saved can help for that)
To be clear, I'm not suggesting a memory leak per se. If I load the save 16 meg data file using the python NBT library, it consumes over 2 gigs of RAM. Ditto NBT explorer, based on .NET. There's something common to how all three implementations store the object in memory that's causing this bloat.
There's a couple of different things going on here.
In 1.6, ocelots and wolves not have a 2 minute "don't despawn" period where they will persist even if there are no players nearby. If you build a holding pen, use a spawn egg to spawn in some ocelots, and fly straight up over 128 blocks, then I can reliably reproduce that ocelots won't despawn before this period, but will despawn after it. So there's no bug with ocelots *de*spawning, per se.
However ocelots do seem to be spawning more which, combined with the 2 minute immunity, means there are many many more ocelots being encountered. Whether this is a bug or intended behaviour is something only Mojang can answer.
just to further comment on this, there is a known bug where leads will break. But some horses that have been confirmed to disappear were fenced in, not tied
edit: Rocco, can you confirm your server is vanilla? /spawn shouldn't do anything on vanilla
"as wild ones can despawn naturally "
<Dinnerbone> Frymaster, in vanilla they should never despawn
While at one point in the snapshots this was the case, it has been confirmed by the devs that even untamed horses shouldn't despawn
edit: Also, confirming I have also had horses despawning
Rode horse in nether, almost to home, left it in an enclosed area because the area on the other side of my portal was open and my underground base didn't have a horse-accessible entrance yet. Later on, the horse has disappeared.
2 horses near spawn have - probably - also disappeared, though as it's a multiplayer server I can't confirm
yup, still broken. Will check latest snapshot next chance I get
EDIT: also still broken
It's not related to elevation, because this still happens with a 2-high or 3-high fence - you can't place fence blocks to prevent this, so all you're really saying is "you can get around the fence bug by not using fences"
@Arthur
Just an FYI:
Your wierd habit of capitalising the first letter of every word is really difficult to read. I'm not trying to be annoying, it's genuinely hard to read your comments
Editing to note that it affects the current prerelease (1.4.3) as well. Also, as expected, it also bugs out on stone walls (basically any block that should be impassible but has a collision box smaller than a whole block)
Right now, if the server was in offline mode in first-run, you permanently lose the chance to convert your existing ops, whitelist and bans to uuids. Obviously responsible admins will have backups, but I do think being able to convert afterwards could be useful