Client crash on KickPlayer(Playername, Reason) about cuberite HOT 23 CLOSED

I cannot reproduce this. I /kick-ed myself and the client survived with no problem. Does this happen all the time, or is it random behavior?

from cuberite.

This happens sporadically (interestingly, less often than when I first reported...), but it happens for me. I have the MC crash logs, though they probably won't be of any help. I have launcher v1.1.4 and client v1.6.2, if that helps.

Additional info:

---- Minecraft Crash Report ----
// I feel sad now :(

Time: 02/08/13 11:11
Description: Exception in world tick

java.lang.NullPointerException
at bct.a(SourceFile:368)
at fe.a(SourceFile:39)
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)

A detailed walkthrough of the error, its code path and all known details is as follows:

-- Head --
Stacktrace:
at bct.a(SourceFile:368)
at fe.a(SourceFile:39)
at cn.b(SourceFile:354)
at bct.e(SourceFile:98)
at bda.b(SourceFile:60)

-- Affected level --
Details:
Problem: Level is null!
Stacktrace:
at ats.k(SourceFile:1386)
at ats.S(SourceFile:663)
at ats.d(SourceFile:619)
at net.minecraft.client.main.Main.main(SourceFile:101)

-- System Details --
Details:
Minecraft Version: 1.6.2
Operating System: Windows 8 (amd64) version 6.2
Java Version: 1.7.0_25, Oracle Corporation
Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation
Memory: 157634568 bytes (150 MB) / 259063808 bytes (247 MB) up to 954466304 bytes (910 MB)
JVM Flags: 2 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xmx1G
AABB Pool Size: 33702 (1887312 bytes; 1 MB) allocated, 53 (2968 bytes; 0 MB) used
Suspicious classes: No suspicious classes found.
IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0
Launched Version: 1.6.2
LWJGL: 2.9.0
OpenGL: AMD Radeon HD 7420G GL version 4.2.11774 Compatibility Profile Context, ATI Technologies Inc.
Is Modded: Probably not. Jar signature remains and client brand is untouched.
Type: Client (map_client.txt)
Resource Pack: Faithful.zip
Current Language: English (UK)
Profiler Position: N/A (disabled)
Vec3 Pool Size: ERROR NullPointerException: null

I also like the: JVM Flags - ...MojangTricksIntelDriversForPerformace...

from cuberite.

The crash logs would probably be helpful, as it's likely a bad packet.

from cuberite.

I don't know, ProtoProxy doesn't even recognise the packet/whatever the server sends the client, so the client isn't even kicked when routing through ProtoProxy.

from cuberite.

Seems to me like a bug in the client. And anyway this is hardly reproducible, I'm inclined to close this issue, agree?

from cuberite.

I seem to get it every time though. Oh yeah, wiki.vg states that there is a race condition in the client with the kick packet so the server can't close the connection the moment it send the packet, but needs to wait a while (or just wait for the client to close the connection). See the documentation on the kick packet.

from cuberite.

Keeping the connection open, waiting for the client to close it, is considered a serious security issue in the networking world. It would be an attack vector for a very simple DDoS - just bombard the server with connection requests and don't close the connections.

I'll add a little delay before forcing the connection close.

from cuberite.

Funny thing. If I use "kick MyFullPlayerName", the client survives. If I use only partial match "kick MyFu", I'm kicked but the client crashes. Seems 100% reproducible this way. WTF?

from cuberite.

No, this is hopeless, even if I give the client 5 seconds to close the connection, it still crashes. And it closes the connection on me, so it's in no way the server's fault.

from cuberite.

I don't think there's anything more we can do, closing the issue.

from cuberite.

It's still an issue, and now we know how to reproduce it, so I don't think it should be closed.

from cuberite.

But the issue is client-side, not server-side. There's nothing the server can do about it.

from cuberite.

Hm. When the client does a /kick chees (incomplete name), it does a sort of tabcomplete thing doesn't it? Presumably, the tabcomplete code sends something wrong in the packet to disconnect the client, and it breaks.

Also, do we need a silent tabcomplete when there is already an 'official' tabcomplete with the tab key?

from cuberite.

The client doesn't do any silent tabcompletion, the server matches the best username to the partial username given (cWorld:FindAndDoWithPlayer() does that).

Also, I was giving that command on the server console, so the client didn't do anything.

from cuberite.

But I mean that when the server does it's auto complete, it must send a bad kick packet to the client which crashes it.

from cuberite.

The packet is the same in both cases. It was actually a false positive, later that evening I got the behavior completely reversed - full name crashed, partial name survived. Then everything crashed, and finally in the end, the client survived everything. It is completely random.

from cuberite.

loooool

Well, we really can't do anything then.
I guess if someone was kicked, then they may have deserved a crash. :D

from cuberite.

Derp maybe.

from cuberite.

One idea that I got during the night - we might be sending packets to the client after we've sent the kick packet. This could be the cause of the crash - imagine a SetBlock packet comes after a kick, the client must be thinking, wtf? I'm gonna fix that.

from cuberite.

Yup, this seems to have done the trick.

from cuberite.

?

from cuberite.

16e3242 fixed it for me.

from cuberite.

Oh, I reopened it because you reverted the "fix", and thought that meant the issue was not fixed anymore.

from cuberite.