Invalid dimension IDs crash the client. WorldServer assumes that anything the server says is immaculate, and increasingly this is not the case.
What I expected to happen was...:
Client would default to dim 0 if the server sent a bad packet
What actually happened was...:
Crash and stack trace:
Time: 7/30/13 12:56 PM
Description: Exception in world tick
java.lang.NullPointerException
at abv.<init>(SourceFile:120)
at bda.<init>(SourceFile:36)
at bct.a(SourceFile:674)
at fg.a(SourceFile:28)
at cn.b(SourceFile:354)
at bct.e(SourceFile:98)
at bda.b(SourceFile:60)
at ats.k(SourceFile:1386)
at ats.S(SourceFile:663)
at ats.d(SourceFile:619)
at net.minecraft.client.main.Main.main(SourceFile:101)
Steps to Reproduce:
I apologize, this bug is hard to reproduce without a modded server, but such servers are widespread, and trusting mod authors is bad. Modding actually tends to make the client more resistant to this bug, although not by much.'
1. Configure a Bukkit or Spigot server with a small plugin to send a packet 0x09 (the respawn packet) to the client with an invalid dimension/environment id. We tested with "18".
2. Start the server and connect a vanilla client to it.
3. Activate the plugin, sending the packet to the client.
Hope this helps. It's an easy fix (one input validation), but it'll smooth things over going towards Workbench. If you don't care about modded servers crashing clients, feel free to ignore and close.
Linked issues
Attachments
Comments 2
I do not believe this to be a duplicate, as it is unrelated to both joining and chatting, in spite of nearly identical stack traces. If it is, then this is probably the most valuable out of all the 403 current reports, because it's the only one I see that actually expresses a process for reliable duplication on a vanilla client.
Based on a crash report provided in this issue, I believe with high certainty that this report may be a duplicate of MC-20163. You can view all information known about this specific crash at MCX-887.