PaperMC / Waterfall

BungeeCord fork that aims to improve performance and stability.
https://papermc.io
MIT License
743 stars 297 forks source link

[Bungee] [Waterfall] [1.19 Spigot Server] Internal Exception: io.netty.handler.codec.DecoderException #751

Closed Hax100 closed 2 years ago

Hax100 commented 2 years ago

When I am in the 1.18.2 lobby and I execute the command "/server UpdatedSurvival" to go to 1.19 survival server, it does not work. Obviously, I have via versions and stuff all set up but it keeps disconnecting me with this error. [12.06 11:03:12] [Disconnect] /xxx.xxx.xxx.has disconnected, reason: Internal Exception: io.netty.handler.codec.DecoderException: java.lang.IndexOutOfBoundsException: readerIndex(8) + length(1) exceeds writerIndex(8): PooledUnsafeDirectByteBuf(ridx: 8, widx: 8, cap: 8)

electronicboy commented 2 years ago

We do not provide support for environments running protocol hacks, make sure that you're using the latest version of waterfall (495, at the time of writing)

Hax100 commented 2 years ago

so.. who does provide support for "environments running protocol hacks"?

electronicboy commented 2 years ago

Generally the people whose protocol hacks you're using; All we can see is that apparently you got a mangled packet, and bungee doesn't log out such info

Hax100 commented 2 years ago

i am not even sure what "protocol hacks" I am using lol. do you mean the ProtocolLib plguin? I contacted them already, but they don't know how to solve it, they need "further stack trace" and there is no error other than that one error I sent.

electronicboy commented 2 years ago

I mean viaversion, plugins on the server sending packets can also cause issues, etc; bungee explicitly cuts off the stack trace, so there's no sane means to get it without attaching a profiler or something

Hax100 commented 2 years ago

so my only solution is the attach a profiler and do a stack trace then send that to viaversion support and they might have a solution?

electronicboy commented 2 years ago

That's basically the only means of finding the actual exception and what packet, etc, blew up while being read, without modifying the proxy itself to actually print out that info

Hax100 commented 2 years ago

EDIT: ok i figured it out.