MC-209819Server crash when pathfinding to player that is teleporting away
I've had this crash dozens of times throughout 1.16.x (and possibly earlier) on my public vanilla server. It's not easy to reproduce as it does not happen frequently, but every time it does happen it's because a player has teleported away from an area while there were mobs aggroed by him, as far as I can tell always zombified piglins.
There are 2 teleportation mechanisms on the server, both can trigger this crash:
1 - summon an armorstand, execute a function as that armorstand which sets its Pos field and then teleports the player in question to itself.
2 - teleport to another player directly through functions.
When crashing, the server takes takes 60 seconds until it times out. I have attached 4 de-obfuscated crash reports. I can provide more if necessary, but they all follow a similar pattern.
Edit: Was able to reproduce it. https://www.youtube.com/watch?v=DFa4wSobUY8
Environment
Details:
Minecraft Version: 1.16.4
Minecraft Version ID: 1.16.4
Operating System: Linux (amd64) version 4.15.0-128-generic
Java Version: 1.8.0_271, Oracle Corporation
Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode)
CPUs: 8
JVM Flags: 2 total; -Xmx6144M -Xms6144M
Is Modded: No
Type: Dedicated Server
Linked Issues
LowAttachments8
Created Issue:
Server crash when pathfinding to player that is teleporting away
I've had this crash dozens of times throughout 1.16.x (and possibly earlier) on my public vanilla server. It's not easy to reproduce as it does not happen frequently, but every time it does happen it's because a player has teleported away from an area while there were mobs aggroed by him, as far as I can tell always zombified piglins.
There are 2 teleportation mechanisms on the server, both can trigger this crash:
1 - summon an armorstand, execute a function as that armorstand which sets its Pos field and then teleports the player in question to itself.
2 - teleport to another player directly through functions.When crashing, the server takes takes 60 seconds until it times out. I have attached 4 de-obfuscated crash reports. I can provide more if necessary, but they all follow a similar pattern.
Environment
Details:
Minecraft Version: 1.16.4
Minecraft Version ID: 1.16.4
Operating System: Linux (amd64) version 4.15.0-128-generic
Java Version: 1.8.0_271, Oracle Corporation
Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode)
CPUs: 8
JVM Flags: 2 total; -Xmx6144M -Xms6144M
Is Modded: No
Type: Dedicated Server
Attachments4
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
relates to
I've had this crash dozens of times throughout 1.16.x (and possibly earlier) on my public vanilla server. It's not easy to reproduce as it does not happen frequently, but every time it does happen it's because a player has teleported away from an area while there were mobs aggroed by him, as far as I can tell always zombified piglins.
There are 2 teleportation mechanisms on the server, both can trigger this crash:
1 - summon an armorstand, execute a function as that armorstand which sets its Pos field and then teleports the player in question to itself.
2 - teleport to another player directly through functions.When crashing, the server takes takes 60 seconds until it times out. I have attached 4 de-obfuscated crash reports. I can provide more if necessary, but they all follow a similar pattern.
Edit: Was able to reproduce it. https://www.youtube.com/watch?v=DFa4wSobUY8
Very Important![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
[Mojang] slicedlime![[Bot] Piston](../../../data/avatars/users/31202.png){kind=small}
The server shuts down automatically because of too much lag.
We do not have enough information to find the cause of this issue.
While the lag occurs, please run /debug start, wait a while and then run /debug stop in order to create a debug profile. Afterwards, run /debug report.
If you do not have the permission to run these commands, open your world to LAN and enable cheats. If you're on a server, make sure that you're a server operator in order to execute these commands.
Then, please attach the profile results found in minecraft/debug/profile-results-<DATE>.txt, as well as the debug report found in minecraft/debug/debug-report-<DATE>.zip here.
This issue is being temporarily closed as Awaiting Response. Once the requested information has been delivered, the report will be reopened automatically.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
What on earth are you talking about? No it does not shut down because of too much lag. The server runs perfectly fine until it suddenly stops responding and the watchdog kills it exactly 60 seconds after the teleport.
In two of the crashes I've attached there is a single person online running a run-of-the-mill gold farm, the TPS was most certainly at 20 until the second the player teleports away.
Does
MC-63590describe your issue?No. It doesn't. Just read the crash dump: they all have an almost identical stack trace with the commonality that a zombified piglin tries to pathfind and that function call takes more than 60 seconds to complete, exceeding the watchdog timer.
Linking some other random report does not help, and this is frankly starting to feel insulting...
Does the issue happen without having any datapacks enabled? If not, please attach the affected data pack. It has probably some error that causes the function to loop indefinitely.
Read. The. Crash. Dump.
I've gone the extra mile to de-obfuscate it, yet you keep asking questions you could rule out by looking at it for a minute.
If every time the watchdog kills the server is during the pathfinding of a zombified piglin it's clearly not the datapack that's at fault here, is it?
The functions in charge of teleporting contain a simple 'tp @s ~ ~ ~' executed at the right position and it gets called through #minecraft:tick. It does not mess with any other entities nor force-load chunks.
Now please stop insulting my intelligence or wasting my time by not bothering to look at the crash dump.
Your crash reports don't suffice to be able to reproduce this issue, and your description doesn't either. Closed as incomplete.
Please take a look at the Bug Tracker Guidelines before creating further bug reports.
I've taken a look at the crash dump. Thank you for trying to be helpful by deobfuscating it... but you actually made it a bit more confusing. Looking at the bottom of the stacktrace, there is this:
which just doesn't make any sense at all (isSingleplayerOwner is on both lines 257 and 811, and there are multiple functions on lines 257 and 811 as well somehow?) I'm not even sure how it ended up in this state (possibly incorrect handling of overloaded obfuscated names; multiple functions named a exist and are disambiguated by the signature or the line number); as far as I can tell those lines should be something like this:
at net.minecraft.server.MinecraftServer.a(SourceFile:811) at net.minecraft.server.MinecraftServer.w(SourceFile:670) at net.minecraft.server.MinecraftServer.a(SourceFile:257) at net.minecraft.server.MinecraftServer$$Lambda$3311/1397283620.run(Unknown Source)Based on what I can understand from your description, what you're trying to describe is a mob trying to pathfind to a player that's teleported a long distance away, causing the server to hang. The crash report isn't inconsistent with that (the top is at least consistent with getChunk being called repeatedly, which I think could happen if pathfinding goes through unloaded chunks, though I'm not sure of that). I would expect the game to cancel pathfinding if the distance is too large, but perhaps that doesn't happen with however you've set it up.
This vaugely reminds me of MC-149563, where entities will still try to pathfind after changing dimensions (though that's not an issue I've reproduced myself).
The link to
MC-63590and a request for a profile report is standard for watchdog crashes, as usually the crash itself is not informative (a random part of the tick) and it's just the server being too laggy. In this case, though, since you've got more or less the same report each time, it does seem like it's an actual hang in one part of the code (or being stuck in chunk loading due to it being repeatedly called).Can you attach a non-deobfuscated crash report, please? Also, when the crash happened, do you know if the area that was teleported from was some place that would remain loaded afterwards? (Possibly due to other players, but in 2 of your reports you have Player Count: 1 / 50 so it can't require a second player to keep the area loaded.)
I have attached the same crash dumps in non-deobfuscated form now. And yes, that's exactly what it looks like.
Yes that description is correct; my guess was that either the entity doesn't do a dimension check or it tries to pathfind to the player's coordinates but in the wrong dimension or is in some kind of dead-lock, but since I'm not familiar with the source code I didn't want to start theory-crafting.
MC-149563 may be related, but it's hard to tell as the events leading up to it are quite different.
I've asked some of the players that were online as the crashes occurred. I can confirm that this crash has happened at times when the area left behind was being loaded by another player as well as when there was no-one else around. The mob farms that triggered this crash are all in areas that are not permanently loaded for performance reason, so regular unloading should occur eventually.
In addition, at least one of the crashes was apparently triggered by using a regular nether portal, which I was not aware of until now, but without knowing when that was the case I can't pull up the exact crash report. So I'd take that with a grain of salt.
Also of note: the players involved sometimes see the area they wanted to go to and sometimes the terrain isn't able to load in in time before the crash, so the time-frame between teleporting away and the start of the hang-up must be quite short.
I understand that you must get a lot of people seeing "Watchdog Error" and immediately posting an unhelpful bug report on it, I just didn't expect to still get dismissive questions 3 comments in.
Deobfuscating crash-2020-11-05_08.46.03-server.txt
, I get this:
crash-2020-11-05_08.57.57-server.txt
is the same, while crash-2020-12-24_17.39.33-server.txt
and crash-2020-12-13_18.37.43-server.txt
are slightly different (they're missing ZombieAttackGoal.tick and Zombie.tick, and have EnderMan.aiStep (bdg.k) instead of Zombie.aiStep). But they both share MeleeAttackGoal, which makes sense (ZombieAttackGoal is a subclass of it). Note that Zombie.tick showing up is consistent with it being zombified piglen, as ZombifiedPiglin subclasses Zombie and doesn't have its own tick or aiStep.
MeleeAttackGoal.tick first checks if the attacking entity can see its target. It does this through Sensing.canSee, which calls LivingEntity.canSee which performs a ray-trace. Sensing does appear to have some form of caching, but it looks like it's cleared every tick. The actual ray-tracing doesn't seem to have any dimension checks (it always uses the attacker's world), nor does it make some kind of sanity check as to the distance between entities; based on the crash reports, it looks like this ray-tracing is able to load chunks. MeleeAttackGoal.tick does check the distance between entities, but only uses it to update a counter (ticksUntilNextPathRecalculation) for performing pathfinding and still performs the ray-trace each tick. The path-finding is much more expensive compared to the ray-trace, but if either are loading chunks, it's still super expensive, and I don't see a reason why it shouldn't check the counter first. Checking the counter first wouldn't solve this problem, but it would still reduce the number of ray-traces.
I'm guessing that the following are needed to reproduce this bug:
I think that placing a large number of mobs in spawn chunks in a superflat world, letting them agro, and then teleporting away will be enough to reproduce this issue. I'll test it, but for now, this issue is at least plausible enough for me to re-open it.
Some additional questions:
Tested it according to instructions and it does work (https://www.youtube.com/watch?v=DFa4wSobUY8). It's a superflat world opened in LAN with a second player loading the area, as I found that /forceload does not seem to be enough to trigger it, or at least with a much lower probability.
As you can see in the footage the 'Client Chunk Cache' counts up rapidly as it not only tries to load the chunks in the path to the player, but actively generates missing ones. Since it will happily do this forever though, I don't get a crash-dump using this setup, however it does trigger consistently.
This might be the same issue as
MC-202249?I'm pretty confident it's the same issue, yes.
Yeah, i do think it's the same.. The issue only occurs at very high distances from 0, 0.