MC-100382DEV - Pathfinding Memory Leak
We have identified a memory leak in Minecraft's Pathfinding System.
In MCP Naming, the NodeProcessor class (PathfinderAbstract in mc-dev naming) is the culprit.
First parameter is IBlockAccess, which is set by the first method in the class. This parameter is set to an instance of a Chunk Cache.
However, the 2nd method called postProcess in MCP, never cleans up this reference.
This causes an Entity's Pathfinding instances to hold onto a reference of a ChunkCache.
This ChunkCache then holds references to many Chunks, even after they unload.
These unloaded chunks then hold references to other leaked Entity objects, who also have references to Pathfinders...
This leaks to potential to create a chain of leaked objects.
Attachments1
Created Issue:
DEV - Pathfinding Memory Leak
We have identified a memory leak in Minecraft's Pathfinding System.
In MCP Naming, the NodeProcessor class (PathfinderAbstract in mc-dev naming) is the culprit.First parameter is IBlockAccess, which is set by the first method in the class. This parameter is set to an instance of a Chunk Cache.
However, the 2nd method called postProcess in MCP, never cleans up this reference.
This causes an Entity's Pathfinding instances to hold onto a reference of a ChunkCache.
This ChunkCache then holds references to many Chunks, even after they unload.
These unloaded chunks then hold references to other leaked Entity objects, who also have references to Pathfinders...
This leaks to potential to create a chain of leaked objects.
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
Saw today's release fixing MC-100382, thought it might also fix this. But no, the zombie pigmans are still freezing in midair in 16w14a
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
[Mod] Neko My MC-100382 has nothing to directly do with performance issues of the pathfinding system itself. and would not directly relate to MC-17630
That bug fixed in 16w14a is a slow leak, that's been in Minecraft for years, and plenty of servers run fine for hours/days on end.
Memory leaks (like MC-100382) can/could, after a while, cause lagging/slowdown/whatnot after they have taken all free memory (or they can more likely just crash the game), but this particular issue was observable even immediately after starting and loading into a world which was left during night. It didn't take but a moment for the zombies to get wild in their pathfinding efforts...
Note also, "freezing midair" was not a common symptom for this bug (if observed at all)... "rubberbanding" (for everything) and related issues were. That is, if you again notice that XP orbs seem to not get collected when should and occasionally "jump" a bit, other things teleporting various distances repeatedly, difficulty to activate doors or basically to do anything, things moving slowly (on the average, even if short-term movement is faster)... all those at situations where a number of zombies can be expected (or seen) to be around (e.g. in tunnels or at surface during night) and within aggro distance of you/villagers (and the aggro distance used to be surprisingly large). Especially, if removing all zombies (e.g. by switching to peaceful) immediately (well, after the queued activities are completed) solves the problems, this issue might be the reason. (I'm not sure how that particular memory leak would behave with such zombie-wipe; the description didn't give enough details.)
Please note that the only person that attached terrain generation to this bug was Steve Mortensen, I have not noticed any change in the behavior of terrain generation associated with the transition from 15w47c to 15w49a, which is what this bug report is explicitly about.
It is not about generalized server lag, it is about a huge dip in performance that started in 15w49a, and is directly related to pathfinding (which was also one of the major changes introduced in 15w49a). There is detailed analysis that demonstrates this in the comment chain.
It seems entirely possible that this bug could exacerbate the memory leak described in MC-100382 but given the age of the underlying problem in that bug, it seems unlikely to be the root cause.
My fix patch can be seen here: https://hub.spigotmc.org/stash/projects/SPIGOT/repos/CraftBukkit/commits/f92e01ba5cf
I think I am able to confirm.
[Edit: I am definitely able to confirm]
Interesting. I've yet to try your patch, and to see if it just works for you or if it works for both of us.
Good catch.
The reference was indeed never release. Thanks for pointing it out.
Is this the cause of
MC-94438?Possibly, we'll see if that gets fixed next version as well
I don't believe so, as this memory leak also affects 1.8.
I wonder if
MC-94438has to do with Grass blocks triggering Chunk Loads for Light Level checks.As that is another flaw we've recently found.
My quick bandaid for that in paper is to return 0 for unloaded chunks light level... Which should only ever happen for blocks that gather light data from neighbor, and that would result in it using 1 of the other 3-4 neighbors.
Maybe thats good enough for Vanilla to do?
See
MC-100341for that.[Mod] redstonehelper Yeah I'm saying
MC-100341and alsoMC-98994might be related to the cause ofMC-94438, since the latter is a very generic "I'm Lagging".WHAT IS THIS BUG it's more like a "Security Issue"
SuperKawaii no, it is not. This bug has been in Minecraft for years, and not something players can intentionally trigger at a scale to crash a server.