Minecraft crashes randomly while playing remotely one someone else's world. After this, attempts to rejoin the world fail with either "unable to join world" or minecraft crashing with high memory usage. This is specific for the gamertag/microsoft account, and occurs when attempting to join from other devices with the same gamertag/microsoft account. It also occurs when attempting to join from an Android device, though it will just show a blue pale screen. It is also world-specific, as it doesn't occur with different worlds.
Opening the world in rbedrock (R library for world analysis), the remote_player key contains a the value "Rotation" which has NaN for the first value, and -90 for second value.
If these are both set to '0', the player can rejoin the world without problems.
I've attached the values from rbedrock that seem to be the cause of the crash - you can see one player has NaN for the first value of Rotation, but not the other. This is associated with the player who is unable to join.
Related issues
is duplicated by
relates to
Attachments
Comments
migrated
migrated
I can confirm I've seen this bug. Whatever the mechanism that leads to the corruption of the remote data held on the server the player will not be able to join from any BedRock edition client thereafter (tested with Android x86/arm64 and PS4 clients). Generally the screen may start up with item bar and a blank void before eventually crashing the client. The only way to restore login is to manually edit the world data to a sane rotation value.
I suspect the best way to approach this is to defensively handle NaN values when first loading the player location and restoring a sane default when it's broken.
migrated
I suspect MC-201406 is a duplicate although in that case they edited the world data with a remote 3rd party tool. In my case the data was caused by gameplay in the client and I could only restore access by using a 3rd party tool to fix the corrupted data.
migrated
Looks like this issue can be fixed without 3rd party tools. In my case (world was at Bedrock Dedicated Server) it's fixed by teleporting bugged player to other player(or to himself)
migrated
@Randi: how do you teleport a player if they can't log in? AFAICT you can only act on players who have logged in.
migrated
I think if you join the world from an android device, rather than just crashing, it seems to show a blank blueish screen. You can then fix it by teleporting, which I guess is the equivalent of editing the player position in rbedrock.
migrated
I should also point out that so far I have only seen this problem with minecraft bedrock linux launcher - though it can happen on a world hosted on any platform. So far haven't had it happen from ipad/win10/android yet (but our usage is heavily skewed to linux use). The launcher provides linker, libc, libm, opengles, jni - so maybe the issue is somewhere there?
migrated
OK it's a race - you can issue a "tp PLAYER" on the server console after the player logs in and before the client crashes and that fixes it although you might need to restart the client. It's certainly faster than shutting everything down and exporting the map data to another machine to tweak and send back.
As to what causes it I'm still not sure. I thought maybe the input code may have passed a dud value into the minecraft code but so far my printf instrumentation hasn't found anything. If I find some spare time over the holidays I might try instrumenting the code via QEMU and see if I can identify where various NaN's appear. My simple hack of feenable(FE_INVALID) before calling the main code unfortunately triggers quite early on. It seems NaNs are pretty common.
migrated
I'm able to recreate these seemingly at will if I log into my Bedrock Dedicated Server on my flat skyblock world using mcpelauncher (https://flathub.org/apps/details/io.mrarm.mcpelauncher) via Linux, go to the Nether, then fall into the lava. Appears to happen every time. Doing the same workflow when logged into the same server via Android does not exhibit the same behavior, hence my original thought that this was an issue with mcpelauncher, rather than a Minecraft-specific issue. Sounds like that might reflect others' experience as well?
migrated
Falling in lava or digging under water (or in fact moving underwater) seem to be common themes to trigger the bug. While it could be mcpelauncher it might be just an x86'ism caused by something going through the funky x87 80bit floating point handling. It's hard to rule out mcplauncher because x86 builds of Minecraft are fairly rare due to the distinct lack of x86 android tablets/phones. I have a x86 Chromebook which has an Android runtime but for some reason Minecraft is blacklisted in the play store on it.
migrated
Same as I said on MCPE-125201 , Mojang can fix that by checking the StartGamePacket for NaN values in Pithc/Roll. This at least fixes the user to login.
For bedrock server, I did a fix-up by hooking the StartGamePacket WriteBinary: https://github.com/racerxdl/bedhock/blob/main/src/hooks/fixes.cpp#L23-L29
This does not avoid the issue of the NaN values to happen, but at least they are able to login afterwards. I also did a check on PlayerAuthInputPacket, so the server doesnt save NaN values there as well
https://github.com/racerxdl/bedhock/blob/main/src/hooks/playerState.cpp#L45-L54
migrated
I'm still trying to check where that does happen, but it seens to be always related when the camera tilts due suffocating by something (lava, water, gravel, sand etc...)
I also can confirm that still affects 1.18
migrated
Is this still an issue in the latest version?
migrated
@Magdalena Wardak I couldnt reproduce the same issue on 1.18.2 with the same scenario. So looks good to me 😃
migrated
I've been playing around with the recent 1.18.2.03 build and doing a lot of underwater digging and so far nothing has tripped up. @Magdalena was there an explicit fix added to the build for this.
migrated
If there was a fix - I know nothing of it. Thanks for letting me know it works now.
Closing.