Barney Gale
- barneygale
- barneygale
- Europe/Stockholm
- Yes
- No
MC-10984![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
MCL-40barney@invert:~$ java -version java version "1.7.0_04" Java(TM) SE Runtime Environment (build 1.7.0_04-b20) Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)barney@invert:~$ java -version
java version "1.7.0_04"
Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
The GS4 Query protocol that minecraft uses is described here, and can be enabled with `enable-query=true` in server.properties.
In short, in full stat mode, the server sends an empty player list if `count(players) > 127`.
The exact bug is slightly more subtle. Excerpt from the query server:
/* 187 */this.u.a("player_");/* 188 */this.u.a(0);/* *//* 190 */ ObjectlocalObject= this.b.A();/* 191 */inti1= (byte)localObject.length;/* 192 */for (inti2= (byte)(i1- 1);i2>= 0;i2 = (byte)(i2 - 1)) { /* 193 */this.u.a(localObject[i2]);/* */} /* */ /* 196 */this.u.a(0);The byte cast causes the player list length variable to overflow, and as the loop counts backwards to zero, no players are sent when the count is 128-255. Beyond this the pattern repeats (i.e. with 300 players online, 44 would be listed), so the players list is only reliable for 127 players or fewer.
The GS4 Query protocol that minecraft uses is described here, and can be enabled with `enable-query=true` in server.properties.
In short, in full stat mode, the server sends an empty player list if `count(players) > 127`.
The exact bug is slightly more subtle. Excerpt from the query server:
this.cachedReply.write("player_"); this.cachedReply.write((int) 0); String [] astring = this.server.getPlayers(); byte b0 = (byte) astring.length; for (byte b1 = (byte) (b0 - 1); b1 >= 0; --b1) { this .cachedReply.write(astring[b1]); } this.cachedReply.write(( int) 0);The byte cast causes the player list length variable to overflow, and as the loop counts backwards to zero, no players are sent when the count is 128-255. Beyond this the pattern repeats (i.e. with 300 players online, 44 would be listed), so the players list is only reliable for 127 players or fewer.
The GS4 Query protocol that minecraft uses is described here, and can be enabled with `enable-query=true` in server.properties.
In short, in full stat mode, the server sends an empty player list if `count(players) > 127`.
The exact bug is slightly more subtle. Excerpt from
the query server:this.cachedReply.write("player_"); this.cachedReply.write((int) 0); String[] astring = this.server.getPlayers(); byte b0 = (byte) astring.length; for (byte b1 = (byte) (b0 - 1); b1 >= 0; --b1) { this.cachedReply.write(astring[b1]); } this.cachedReply.write((int) 0);The byte cast causes the player list length variable to overflow, and as the loop counts backwards to zero, no players are sent when the count is 128-255. Beyond this the pattern repeats (i.e. with 300 players online, 44 would be listed), so the players list is only reliable for 127 players or fewer.
The GS4 Query protocol that minecraft uses is described here, and can be enabled with `enable-query=true` in server.properties.
In short, in full stat mode, the server sends an empty player list if `count(players) > 127`.
The exact bug is slightly more subtle. Excerpt from RemoteStatusListener.java:
this.cachedReply.write("player_"); this.cachedReply.write((int) 0); String[] astring = this.server.getPlayers(); byte b0 = (byte) astring.length; for (byte b1 = (byte) (b0 - 1); b1 >= 0; --b1) { this.cachedReply.write(astring[b1]); } this.cachedReply.write((int) 0);The byte cast causes the player list length variable to overflow, and as the loop counts backwards to zero, no players are sent when the count is 128-255. Beyond this the pattern repeats (i.e. with 300 players online, 44 would be listed), so the players list is only reliable for 127 players or fewer.
By contrast, the 'this.server.getPlayers()' method is implemented with an int counter in PlayerList.java:
String[] astring = new String[this.players.size()]; for (int i = 0; i < this.players.size(); ++i) { astring[i] = ((EntityPlayer) this.players.get(i)).getName(); } return astring;I also can't think of a reason for the player list to be reversed, as its stored in a largely non-useful order anyway.
Kane, this is related to the GS4 Query handler and not the RCON handler. Don't conflate the two.
Could this bug be reassigned? I think Dan Frisk is busy working on MCPE
Same issue here, though for me it affects 13w38c and 13w39b too! Using integrated intel graphics on Linux.
OpenGL version string: 3.0 Mesa 9.0.3
I am also affected. Using integrated Intel graphics.
barney@pine ~ $ glxinfo | grep "OpenGL version"
OpenGL version string: 3.0 Mesa 9.0.3
barney@pine ~ $ java -version
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)
As far as I can tell, it's org.lwjgl.opengl.GL11.glGenLists which is the culprit, mostly on intel cards. Anyone fancy making a smaller test program to try and replicate the issue?
For what it's worth:
barney@pine ~ $ dpkg -s libgl1-mesa-glx | grep Version
Version: 9.0.3-0ubuntu0.4
This bug affects a variety of graphics cards and drivers, including many modern ones. AFAIK minecraft is the first and only game to die on this bug. I've been playing since alpha and it's going to suck having to stop playing over a bug that's been marked as "invalid" despite its cause not being determined. You can't reasonably say "it's your graphic drivers" if it affects a range of drivers :/
I'm happy to provide a VNC or SSH service to a mojang developer if they want to investigate this further.
Normally when logging in, the client sends a "handshake" packet to switch to protocol mode 2, then sends a "login start" packet with the player's username. When this bug occurs, the first packet on the wire is the "login start" packet, which upsets the server as it's expecting a handshake.
I've been able to reproduce this on a local server by logging on/off repeatedly. In 20 attempts, 9 succeeded and 11 hung on "logging in...". Successes/failures seemed to come in "runs", e.g. 3 or 4 consecutive attempts would be successful, then I'd get 3 or 4 failures in a row.
I believe it will be a ninja edit, i.e. it'll work in 1.7.1 final, which will differ very slightly from 1.7.1 pre.