Client-side disconnect
Teslicek opened this issue ยท 15 comments
[14:32:34] [Render thread/WARN]: Unknown custom packet payload: vp:vp
[14:32:34] [Netty Client IO #12/WARN]: An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.
io.netty.channel.ChannelPipelineException: me.steinborn.krypton.mod.shared.network.compression.MinecraftCompressDecoder.handlerRemoved() has thrown an exception.
at io.netty.channel.DefaultChannelPipeline.callHandlerRemoved0(DefaultChannelPipeline.java:640) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.DefaultChannelPipeline.destroyDown(DefaultChannelPipeline.java:876) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.DefaultChannelPipeline.destroyUp(DefaultChannelPipeline.java:844) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.DefaultChannelPipeline.destroy(DefaultChannelPipeline.java:836) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.DefaultChannelPipeline.access$700(DefaultChannelPipeline.java:46) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelUnregistered(DefaultChannelPipeline.java:1392) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelUnregistered(AbstractChannelHandlerContext.java:215) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelUnregistered(AbstractChannelHandlerContext.java:195) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.DefaultChannelPipeline.fireChannelUnregistered(DefaultChannelPipeline.java:821) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:821) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174) ~[netty-common-4.1.97.Final.jar:?]
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167) ~[netty-common-4.1.97.Final.jar:?]
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470) ~[netty-common-4.1.97.Final.jar:?]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:566) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) ~[netty-common-4.1.97.Final.jar:?]
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.97.Final.jar:?]
at java.lang.Thread.run(Unknown Source) ~[?:?]
Caused by: io.netty.util.IllegalReferenceCountException: refCnt: 0, decrement: 1
at io.netty.util.internal.ReferenceCountUpdater.toLiveRealRefCnt(ReferenceCountUpdater.java:83) ~[netty-common-4.1.97.Final.jar:?]
at io.netty.util.internal.ReferenceCountUpdater.release(ReferenceCountUpdater.java:148) ~[netty-common-4.1.97.Final.jar:?]
at io.netty.buffer.AbstractReferenceCountedByteBuf.release(AbstractReferenceCountedByteBuf.java:101) ~[netty-buffer-4.1.97.Final.jar:?]
at io.netty.handler.codec.ByteToMessageDecoder.handlerRemoved(ByteToMessageDecoder.java:269) ~[netty-codec-4.1.97.Final.jar:?]
at io.netty.channel.AbstractChannelHandlerContext.callHandlerRemoved(AbstractChannelHandlerContext.java:1122) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.DefaultChannelPipeline.callHandlerRemoved0(DefaultChannelPipeline.java:637) ~[netty-transport-4.1.97.Final.jar:?]
... 16 more
[14:32:34] [Render thread/INFO]: Stopping worker threads
[14:32:34] [Render thread/WARN]: Client disconnected with reason: Internal Exception: io.netty.util.IllegalReferenceCountException: MinecraftCompressDecoder#decode() might have released its input buffer, or passed it down the pipeline without a retain() call, which is not allowed.
1.20.4, Krypton 0.2.4
This was actually a Fabric API issue, I have a PR fixing it here: FabricMC/fabric#3508
Mostly it's simply optimized, but with additional QoL mods.
(The cda-mod is custom, it just aligns ESC buttons.)
I don't get this issue when I use Krypton and LazyDFU on 1.20.4, so this is almost certainly a mod compatibility issue
[19:46:16] [Render thread/WARN]: Unknown custom packet payload: vp:vp
[19:46:16] [Netty Client IO #2/WARN]: An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.
io.netty.util.IllegalReferenceCountException: refCnt: 0, decrement: 1
at io.netty.util.internal.ReferenceCountUpdater.toLiveRealRefCnt(ReferenceCountUpdater.java:83) ~[netty-common-4.1.97.Final.jar:?]
at io.netty.util.internal.ReferenceCountUpdater.release(ReferenceCountUpdater.java:148) ~[netty-common-4.1.97.Final.jar:?]
at io.netty.buffer.AbstractReferenceCountedByteBuf.release(AbstractReferenceCountedByteBuf.java:101) ~[netty-buffer-4.1.97.Final.jar:?]
at io.netty.util.ReferenceCountUtil.release(ReferenceCountUtil.java:90) ~[netty-common-4.1.97.Final.jar:?]
at io.netty.channel.DefaultChannelPipeline.onUnhandledInboundMessage(DefaultChannelPipeline.java:1186) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.DefaultChannelPipeline.onUnhandledInboundMessage(DefaultChannelPipeline.java:1196) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.DefaultChannelPipeline$TailContext.channelRead(DefaultChannelPipeline.java:1296) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.handler.codec.ByteToMessageDecoder.handlerRemoved(ByteToMessageDecoder.java:266) ~[netty-codec-4.1.97.Final.jar:?]
at io.netty.channel.AbstractChannelHandlerContext.callHandlerRemoved(AbstractChannelHandlerContext.java:1122) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.DefaultChannelPipeline.callHandlerRemoved0(DefaultChannelPipeline.java:637) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.DefaultChannelPipeline.destroyDown(DefaultChannelPipeline.java:876) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.DefaultChannelPipeline.destroyUp(DefaultChannelPipeline.java:844) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.DefaultChannelPipeline.destroy(DefaultChannelPipeline.java:836) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.DefaultChannelPipeline.access$700(DefaultChannelPipeline.java:46) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelUnregistered(DefaultChannelPipeline.java:1392) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelUnregistered(AbstractChannelHandlerContext.java:215) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelUnregistered(AbstractChannelHandlerContext.java:195) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.DefaultChannelPipeline.fireChannelUnregistered(DefaultChannelPipeline.java:821) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:821) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174) ~[netty-common-4.1.97.Final.jar:?]
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167) ~[netty-common-4.1.97.Final.jar:?]
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470) ~[netty-common-4.1.97.Final.jar:?]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:566) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) ~[netty-common-4.1.97.Final.jar:?]
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.97.Final.jar:?]
at java.lang.Thread.run(Unknown Source) ~[?:?]
[19:46:16] [Render thread/INFO]: Stopping worker threads
[19:46:16] [Render thread/WARN]: Client disconnected with reason: Internal Exception: io.netty.handler.codec.DecoderException: io.netty.util.IllegalReferenceCountException: refCnt: 0, increment: 1
Unfortunately, it still happens.
I'm experiencing the same problem on Minecraft 1.20.4 with only:
- fabric-api 0.92
- sodium 0.5.5
- modmenu 9.0.0
- lithium 0.12.1
- immediately-fast 1.2.8
- starlight 1.1.3
- ferritecore 6.0.3
- entityculling 1.6.3.1
- better-log4j-config 1.1.0
and of course krypton 0.2.4.
This list reduces the search for incompatibilities to only those mods.
Except for better-log4j-config (I guess we can ignore this) this mod list is a subset of the list above.
Note that I only experienced the issue after a few minutes of playing, but not directly after joining.
I hope this information is helpful in finding the cause of this issue.
After some more research, I can somewhat reliably reproduce this issue with only krypton and fabric-api.
The problem may be related to changes in the fabric networking api (see this commit FabricMC/fabric@bd733d6 that introduced changes to "fabric-networking-api-v1/src/client/java/net/fabricmc/fabric/mixin/networking/client/ClientCommonNetworkHandlerMixin.java", first released in fabric-api 0.91).
To reproduce this: Send a bunch of custom payloads to the client, and after a few attempts, the client disconnects. Sometimes it works directly, sometimes it takes a few seconds (maybe a race condition).
Another exception that may be related to this issue (but does not cause disconnects), also only occurs when both krypton and fabric-api are installed:
net.minecraft.class_148: Main thread packet handler
at net.minecraft.class_2600.method_11072(class_2600.java:33) ~[client-intermediary.jar:?]
at net.minecraft.class_1255.method_18859(class_1255.java:156) ~[client-intermediary.jar:?]
at net.minecraft.class_4093.method_18859(class_4093.java:23) ~[client-intermediary.jar:?]
at net.minecraft.class_1255.method_16075(class_1255.java:130) ~[client-intermediary.jar:?]
at net.minecraft.class_1255.method_5383(class_1255.java:115) ~[client-intermediary.jar:?]
at net.minecraft.class_310.method_1523(class_310.java:1283) ~[client-intermediary.jar:?]
at net.minecraft.class_310.method_1514(class_310.java:888) ~[client-intermediary.jar:?]
at net.minecraft.client.main.Main.main(Main.java:265) ~[fabric-loader-0.15.3-1.20.4.jar:?]
at net.fabricmc.loader.impl.game.minecraft.MinecraftGameProvider.launch(MinecraftGameProvider.java:470) ~[fabric-loader-0.15.3.jar:?]
at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:74) ~[fabric-loader-0.15.3.jar:?]
at net.fabricmc.loader.impl.launch.knot.KnotClient.main(KnotClient.java:23) ~[fabric-loader-0.15.3.jar:?]
Caused by: io.netty.util.IllegalReferenceCountException: refCnt: 0
at io.netty.buffer.AbstractByteBuf.ensureAccessible(AbstractByteBuf.java:1454) ~[netty-buffer-4.1.97.Final.jar:?]
at io.netty.buffer.AbstractByteBuf.checkReadableBytes0(AbstractByteBuf.java:1440) ~[netty-buffer-4.1.97.Final.jar:?]
at io.netty.buffer.AbstractByteBuf.checkReadableBytes(AbstractByteBuf.java:1428) ~[netty-buffer-4.1.97.Final.jar:?]
at io.netty.buffer.AbstractByteBuf.skipBytes(AbstractByteBuf.java:971) ~[netty-buffer-4.1.97.Final.jar:?]
at net.minecraft.class_2540.method_52994(class_2540.java:1435) ~[client-intermediary.jar:?]
at net.minecraft.class_8673.handler$zgb000$fabric-networking-api-v1$onCustomPayload(class_8673.java:1053) ~[client-intermediary.jar:?]
at net.minecraft.class_8673.method_52780(class_8673.java) ~[client-intermediary.jar:?]
at net.minecraft.class_2658.method_53024(class_2658.java:94) ~[client-intermediary.jar:?]
at net.minecraft.class_2658.method_11054(class_2658.java:32) ~[client-intermediary.jar:?]
at net.minecraft.class_2600.method_11072(class_2600.java:24) ~[client-intermediary.jar:?]
... 10 more
Well, if it is a Fabric API incompatibility, that means I'm in a bit of a pickle. Still, there might be something I can do here.
@WinPlay02 I was able to confirm your findings here, and I'm looking into a fix.