What happened?

I attempted to join a world via LAN and Elemental, hosted on another machine (same hardware, launcher, and mod-pack, but different OS) but it would frequently (yet inconsistently) fail with any of the undermentioned error messages:

• Reference Count Error

  1. Quotation

     Connection Lost

     Internal Exception: io.netty.handler.codec.EncoderException: io.netty.util.IllegalReferenceCountException: refCnt: 0

  2. Screenshot

     

• Mere Disconnection Error

  1. Quotation

     Connection Lost

     Disconnected

  2. Screenshot

     

Steps to reproduce

1. Environment Configuration

   1. Install the OS:

      • cpe:/o:microsoft:windows:11

        Via microsoft.com/en-us/software-download/windows11 (or microsoft.com/en-us/software-download/windowsinsiderpreviewiso).

        1. #!/usr/bin/env pwsh
           #Requires -PSEdition Core
           #Requires -PSEdition 7.5
           Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" | Format-List

        2. SystemRoot                : C:\WINDOWS
           BuildBranch               : ge_release
           BuildLab                  : 26100.ge_release.240331-1435
           BuildLabEx                : 26100.1.amd64fre.ge_release.240331-1435
           CompositionEditionID      : Enterprise
           CurrentBuild              : 26100
           CurrentBuildNumber        : 26100
           CurrentMajorVersionNumber : 10
           CurrentMinorVersionNumber : 0
           CurrentType               : Multiprocessor Free
           CurrentVersion            : 6.3
           DisplayVersion            : 24H2
           EditionID                 : Professional
           InstallationType          : Client
           InstallDate               : 1719779588
           LCUVer                    : 10.0.26100.2152
           ProductName               : Windows 10 Pro

      • cpe:/o:fedoraproject:fedora:40

        Via Fedora-KDE-Live-x86_64-40-1.14.iso.

        1. #!/usr/bin/env sh
           kinfo

        2. Operating System: Fedora Linux 40
           KDE Plasma Version: 6.2.1
           KDE Frameworks Version: 6.7.0
           Qt Version: 6.7.2
           Kernel Version: 6.11.3-200.fc40.x86_64 (64-bit)
           Graphics Platform: Wayland
           Processors: 12 × AMD Ryzen 5 7600X 6-Core Processor
           Memory: 30.4 GiB of RAM
           Graphics Processor: AMD Radeon RX 7900 XTX

   2. Install Prism Launcher:

      • cpe:/o:microsoft:windows:11 ¹

        #!/usr/bin/env pwsh
        winget install --id 'PrismLauncher.PrismLauncher' --version 8.4

      • cpe:/o:fedoraproject:fedora:40 ²

        #!/usr/bin/env sh
        flatpak install 'https://dl.flathub.org/repo/appstream/org.prismlauncher.PrismLauncher.flatpakref' && \
        flatpak update 'app/org.prismlauncher.PrismLauncher/x86_64/stable' --commit=0e60b64e9454ee7808fa1cd24849debbb1c3efbfc3a6dfa4cf40d4202bceb904

2. Import (and configure) the modifications:

   1. Download kim.nl.tab.digital/s/QsmpqSeZnwsQ2BY.

   2. Create an instance:

      

   3. Select the pack:

      1. 

      2. 

   4. Leave these disabled (or disable them):

      

   5. If you see this, create a new one. You shouldn't see it the first time you do so.

      

   6. Wait for it to extract and import:

      1. 

      2. 

3. Confirmation

   1. Launch the instance.

   2. Host a world on one machine.

   3. Attempt to join it on the other.

      This should consistently work, without any failures.

4. Better Statistics Screen Installation

   1. Install better-stats/version/3.13.2+fabric-1.21 from modrinth.com:

      1. 

      2. 

   2. Enable it (if not already so):

      

5. Confirmation

   1. Launch the instance.

   2. Host a world on one machine.

   3. Attempt to join it on the other.

      If the error doesn't reproduce immediately, continue to attempt to rejoin. It should occur consistently frequently.

Relevant log output or crash report

I've attached it at gist.github.com/RokeJulianLockhart/d2a7ca0b31f2eb45d8e835112749da86. It isn't from after instance closure 1. instead, it's immediately after the reference count error occurred:

Other installed mods

Code of Conduct

1. I agree that if the issue is regarding a crash, I gave the logs and the crash report.
2. I agree that I will be available later for any follow-up questions to help diagnose and resolve the issue.

(Lack of) Duplicates

issues?q=is%3Aissue+is%3Aopen+io.netty.handler.codec.EncoderException returned 0 results at +2024-10-19T10:16:56+01:00.

#142 (comment)

@JaredRichardWilliam can confirm too.

Can confirm I am having this issue as well

Thank you so much for the quick response!

As for

How do you suggest that I log it?

You do not have to do anything regarding the error logging, as I* will be responsible for tracing the error to its origin once I recreate the issue on my end. Actually logging the error would require you to mod the game yourself and program it to do that, which obviously, I do not expect anyone to do (nor should you).

I will now get to reproducing the environment and the issue you have described, after which I'll work on a patch. Hopefully everything goes as planned. Thank you once again, and have a great day!

Hello!
Sorry for the delayed response, as I usually respond sooner.
Now that 1.21.3 ports are out, I'd like to focus on resolving this issue. First off, thank you so much for such a detailed bug report! Very few people put in the effort to try and describe an issue in that much detail.

Now, I'd like to focus on reproducing the issue on my end, so I can find a way to resolve it. To do this, I need to clear up a few issues;

1. Could you please provide information on what "Elemental" is? Apologies for not knowing this already. I tried looking it up, but using the search-term "elemental" is too vague to find meaningful results on Google and other search engines.
2. The link you have provided, https://kim.nl.tab.digital/s/QsmpqSeZnwsQ2BY, is inaccessible to me. I assume this could be a mod-pack or some sort of configs, however I am unable to reach them (Something called "NextCloud" tells me the file is not found).
3. The biggest one so far; Minecraft doesn't log network-related errors, so the log file you have provided has no useful information unfortunately (go figure, something Minecraft should log, isn't coded by Mojang to be logged). Now I understand this isn't an issue on your end, but I am still stating this just so it's known. This network-related error also just so happens to be the main focal point of this issue report, so the best I can do is recreate the issue on my end, given the logs do not have the details I need, and the stack-trace shown on-screen doesn't have enough lines to explain the error's origin.

Once I manage to recreate the issue on my end, it will hopefully help me get closer to the line of code that caused this issue, after which a patch can be made. ((In the meantime, I suppose it'd be a good idea for me to implement (togglable/configurable) network-related error loggers in my mods, if possible.))

Edit:
All edits are typo-corrections.

Could you please provide information on what "Elemental" is? Apologies for not knowing this already. I tried looking it up, but using the search-term "elemental" is too vague to find meaningful results on Google and other search engines.

Apologies. I meant Essential. Filing bugs at night does things to a brain.

The link you have provided, kim.nl.tab.digital/s/QsmpqSeZnwsQ2BY, is inaccessible to me. I assume this could be a mod-pack or some sort of configs, however I am unable to reach them (Something called "NextCloud" tells me the file is not found).

Yeah, that wasn't meant to expire. I didn't upload it, but I'll reupload and provide a permanent URI when @JaredRichardWilliam is available again - it's indeed a modpack, and he created it with prismlauncher-9.0-1.fc40.x86_64.

The biggest one so far; Minecraft doesn't log network-related errors, so the log file you have provided has no useful information unfortunately (go figure, something Minecraft should log, isn't coded by Mojang to be logged). Now I understand this isn't an issue on your end, but I am still stating this just so it's known.

How do you suggest that I log it? I don't mind filing an issue on MC's Jira to eventually have the work performed in the main client, but they'll probably close it as a suggestion (even if I phrase the absence as a bug). Otherwise, I don't mind trying any of the non-destructive options at this Ask Ubuntu answer revision (like WireShark) or superuser.com/revisions/22571/1, but I'm unfamiliar with them.

This network-related error also just so happens to be the main focal point of this issue report, so the best I can do is recreate the issue on my end, given the logs do not have the details I need, and the stack-trace shown on-screen doesn't have enough lines to explain the error's origin.

I'll use debug symbols if you can provide them, but I'm unfamiliar with whether those are necessary for languages like DotNet and Java (considering they use microcode), much less how to install them (considering that gdb's debuginfo shan't install them, and they're not available via any OS's package manager).

#142 (comment)

@TheCSDev, I've re-uploaded the pack at github.com/user-attachments/files/17524982/Redy.s.Pack.Fabric.zip. ¹

Hello again!
If you do not mind, I have one more question I'd like to ask.

In the latest versions of the game (I used 1.21), I intentionally recreated a scenario where the client would get disconnected due to a network error (by intentionally cutting the server's internet access). To my surprise, I noticed the game is actually logging the error in my case, and it even shows me a button to click on it and view the logs;

I was wondering if something like this takes place on your end, and if the game is leaving any more traces of the error. For me, the game saved an error log file in the [game folder]/debug directory.

And here's the example error log file I was able to find:

---- Minecraft Network Protocol Error Report ----
// I heard pigeons are more reliable

Time: 2024-10-26 13:48:49
Description: Packet handling error

java.net.SocketException: Connection reset
	at java.base/sun.nio.ch.SocketChannelImpl.throwConnectionReset(SocketChannelImpl.java:401)
	at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:434)
	at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:254)
	at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132)
	at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:357)
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:151)
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at java.base/java.lang.Thread.run(Thread.java:1583)

Now that I have the time to, I will also recreate a modded environment using your mod-pack and using the scenario you have provided, and see if any traces are left by the game in that instance as well.

-

Edit to add (after some time passed):

I have recreated the environment by installing the mod-pack to my client and to a server hosted on a VM. I made attempts to join the server both with and without BSS installed. In both instances, I encountered no issues, even after repeated rejoins.
Note that the modpack you have provided is 1.20.1, so I don't know if that plays a role. Now, I also know you mentioned Essential, however I am unfortunately unable to use it due to not having two purchased Minecraft accounts. Lastly, I will see if it's possible for me to attempt regular LAN sessions using two non-authenticated clients aka ones used in mod development environments (and not onces found in "cracked" launchers).

If nothing works, then this could be some sort of incompatibility with Essential, but I am unfortunately unable to verify or check this. I will also have a deep look at my networking-related code, specifically one dealing with ByteBuf-s, as the error message you have shown does usually originate from mishandling of ByteBuf-s.

I had this issue on quilt 1.20.1 0.27.0 when joining a single player world, but when I updated to 0.28.0-beta.3 it started to work.

I had this issue on quilt 1.20.1 0.27.0 when joining a single player world, but when I updated to 0.28.0-beta.3 it started to work.

Never mind. Now the issue is back.

I also encountered this bug in version 1.20.1 with the same error message like this:

[01:16:16] [Netty Server IO #2/ERROR]: Error receiving packet 23
io.netty.util.IllegalReferenceCountException: refCnt: 0
	at io.netty.buffer.AbstractByteBuf.ensureAccessible(AbstractByteBuf.java:1454) ~[netty-buffer-4.1.82.Final.jar:?]
	at io.netty.buffer.AbstractByteBuf.checkIndex(AbstractByteBuf.java:1383) ~[netty-buffer-4.1.82.Final.jar:?]
	at io.netty.buffer.UnpooledHeapByteBuf.copy(UnpooledHeapByteBuf.java:534) ~[netty-buffer-4.1.82.Final.jar:?]
	at io.netty.buffer.AbstractByteBuf.copy(AbstractByteBuf.java:1194) ~[netty-buffer-4.1.82.Final.jar:?]
	at net.minecraft.class_2540.copy(class_2540.java:1628) ~[server-intermediary.jar:?]
	at net.minecraft.class_2540.copy(class_2540.java:1628) ~[server-intermediary.jar:?]
	at net.minecraft.class_2658.method_11052(class_2658.java:55) ~[server-intermediary.jar:?]
	at net.minecraft.class_2545.method_10838(class_2545.java:45) ~[server-intermediary.jar:?]
	at net.minecraft.class_2545.encode(class_2545.java:14) ~[server-intermediary.jar:?]
	at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:107) ~[netty-codec-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:717) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeWrite(AbstractChannelHandlerContext.java:709) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:792) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:702) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.handler.codec.MessageToMessageEncoder.write(MessageToMessageEncoder.java:113) ~[netty-codec-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:717) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:764) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:790) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:758) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:808) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:1025) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:306) ~[netty-transport-4.1.82.Final.jar:?]
	at net.minecraft.class_2535.method_36942(class_2535.java:220) ~[server-intermediary.jar:?]
	at net.minecraft.class_2535.method_10761(class_2535.java:212) ~[server-intermediary.jar:?]
	at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174) ~[netty-common-4.1.82.Final.jar:?]
	at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167) ~[netty-common-4.1.82.Final.jar:?]
	at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470) ~[netty-common-4.1.82.Final.jar:?]
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:566) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) ~[netty-common-4.1.82.Final.jar:?]
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.82.Final.jar:?]
	at java.lang.Thread.run(Thread.java:1583) ~[?:?]
[01:16:16] [Netty Server IO #2/ERROR]: Exception occurred in netty pipeline
io.netty.handler.codec.EncoderException: io.netty.util.IllegalReferenceCountException: refCnt: 0
	at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:125) ~[netty-codec-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:717) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeWrite(AbstractChannelHandlerContext.java:709) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:792) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:702) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.handler.codec.MessageToMessageEncoder.write(MessageToMessageEncoder.java:113) ~[netty-codec-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:717) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:764) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:790) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:758) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:808) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:1025) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:306) ~[netty-transport-4.1.82.Final.jar:?]
	at net.minecraft.class_2535.method_36942(class_2535.java:220) ~[server-intermediary.jar:?]
	at net.minecraft.class_2535.method_10761(class_2535.java:212) ~[server-intermediary.jar:?]
	at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174) ~[netty-common-4.1.82.Final.jar:?]
	at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167) ~[netty-common-4.1.82.Final.jar:?]
	at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470) ~[netty-common-4.1.82.Final.jar:?]
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:566) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) ~[netty-common-4.1.82.Final.jar:?]
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.82.Final.jar:?]
	at java.lang.Thread.run(Thread.java:1583) ~[?:?]
Caused by: io.netty.util.IllegalReferenceCountException: refCnt: 0
	at io.netty.buffer.AbstractByteBuf.ensureAccessible(AbstractByteBuf.java:1454) ~[netty-buffer-4.1.82.Final.jar:?]
	at io.netty.buffer.AbstractByteBuf.checkIndex(AbstractByteBuf.java:1383) ~[netty-buffer-4.1.82.Final.jar:?]
	at io.netty.buffer.UnpooledHeapByteBuf.copy(UnpooledHeapByteBuf.java:534) ~[netty-buffer-4.1.82.Final.jar:?]
	at io.netty.buffer.AbstractByteBuf.copy(AbstractByteBuf.java:1194) ~[netty-buffer-4.1.82.Final.jar:?]
	at net.minecraft.class_2540.copy(class_2540.java:1628) ~[server-intermediary.jar:?]
	at net.minecraft.class_2540.copy(class_2540.java:1628) ~[server-intermediary.jar:?]
	at net.minecraft.class_2658.method_11052(class_2658.java:55) ~[server-intermediary.jar:?]
	at net.minecraft.class_2545.method_10838(class_2545.java:45) ~[server-intermediary.jar:?]
	at net.minecraft.class_2545.encode(class_2545.java:14) ~[server-intermediary.jar:?]
	at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:107) ~[netty-codec-4.1.82.Final.jar:?]
	... 21 more

When I disable this Mod on the server, even if the client still loads it, there won't be any issues.

If the error doesn't reproduce immediately, continue to attempt to rejoin. It should occur consistently frequently.

This doesn't appear to reproduce on cpe:/o:fedoraproject:fedora:41 (via LAN and Essential, on prismlauncher-9.2-1.fc41.x86_64). ¹ I wonder whether this relates to how MC or Java interacts with the network stack on cpe:/o:microsoft:windows:11, specifically.

@ninjaguardian and @YELANDAOKONG, what OSes did you use when you encountered this?

Windows 11

#142 (comment)

This potentially partially reproduces ¹ on cpe:/o:microsoft:windows:11 with 9.2.0.0:

However, but it's certainly more stable than beforehand.

I say “partially” because I don't see a ./debug directory in $Env:AppData\PrismLauncher\instances\Redy's Pack (Fabric)(1):

1. #!/usr/bin/env pwsh
   #Requires -PSEdition Core
   #Requires -PSEdition 7.5
   tree "$Env:AppData\PrismLauncher\instances\Redy's Pack (Fabric)(1)" | Select-String -SimpleMatch -Pattern 'debug'

2. $Null

Though, perhaps that's only generated when it segmentation faults?

Irrespective, the problem with the other OS was that I didn't have mc-better-stats installed, because I'm a moron, and thus uploaded the .mrpack without it. ² I'll re-test on fedora:41 again tomorrow.

Environment

#142 (comment)

The .mrpack with mc-better-stats installed is available at user-attachments/files/19406183/TEST.zip. Please replace your previous installation with it, if applicable.

My next best guess is that it could be with the way ByteBuf-s are handled by the codes of my mod and another mod. I will have to look further into this once I get the time.

To explain my current speculation, some technical context;

• A ByteBuf, as the name suggests, is a "byte buffer". It represents a byte array allocated somewhere on the device's RAM. They are commonly used when software deals with binary data. The game's and mods' networking codebases too, often use byte buffers.
• Given a ByteBuf allocates a chunk RAM, said RAM needs to be "released" once the buffer is no longer needed. Not releasing the buffer results in a memory leak (because you then have junk occupying RAM).
• One catch about releasing ByteBufs is, if you attempt to release a buffer that's already been released, the buffer throws a refCnt: 0 error. So before releasing such buffers, it's usually a good idea to first check if it was already released.

Now onto my mod's code. My mod, specifically when dealing with some network and packet related aspects, has to handle buffers and on some occasions even create new buffers, all so it can work with binary data and server/client data exchange as it handles networking packets. As explained above, to avoid memory leaks, my mod has to release the buffers it dealt with, to avoid any memory leaks (I believe this behavior is coming from TCDCommons, as that mod of mine is the one that has a bunch of networking code). And yes, I do in my mods's code make refCnt checks to ensure buffers weren't released prior to releasing them.

Now my speculation is that mayhaps another mod that also deals with networking code, also just so happens to hold a reference to one of the netowrking buffers, and in an assumption nothing else released them, they attempt to release said buffers, causing the refCnt error. So in other words;

1. My mod uses a buffer to deal with binary data
2. My mod checks if the buffer was released, and if not, it releases it to avoid memory leaks
3. Another mod holding the same buffer, also chooses to release the buffer for the same reason, but with an assumption nothing else already released it
4. The refCnt error is thrown.

In other words, my speculation boils down to a conflict in mod behaviors. And the reason I speculate it could be another mod is because this doesn't appear to happen in vanilla instances (by vanilla I mean lack of other mods's presence).

Now if this speculation is true, you may ask "Well, can you just, not release the buffer yourself on your end?", to wich I say;

• "No, it's too risky to let the buffer be. I do not and cannot know if another mod will release the buffer for me, so ignoring it will certainly cause a memory leak if there isn't anything else out there to release it."

At least, that's my best guess. I may look further into this once I get the time. Although, I am hoping a future update I make will fix this issue. As for other mod developers, I'd ask them to make refCnt checks before releasing buffers.

Issue for me happened after updating Geckolib, Balm, Fabric Language Kotlin, Fzzy Config, and Scholar, so not sure which would be the reason.

#142 (comment)

Apologies for the spam. Reproduced, under cpe:/o:fedoraproject:fedora:41 on both server and client, ^{1 2} so it's not OS-bound. However, I still see no debug (nor crash-report) directory, @TheCSDev:

1. #!/usr/bin/env sh
   tree "$HOME/.local/share/PrismLauncher/instances/Redy's Pack (Fabric)/minecraft" | grep -E debug

2. │   │   │   │   ├── debug_chunk_loader.json5
   │   │   │   │   ├── debug_cube_gen.json5
   │   │   │   │   ├── debug_energy_gen.json5
   │   │   │   │   ├── debug_item_gen.json5
   │   │   │   │   ├── debug_phantom_node.json5
   │   ├── debugify-descriptions.json
   │   ├── debugify.json
   │   │   ├── jei-debug.ini
   

Additionally, @YELANDAOKONG, :~:text= with refCnt and connection%20reset return null.

Can confirm it happens on 1.20.1 with Cloudflared too, just started happening today all of a sudden so not sure why.

My next best guess is that it could be with the way ByteBuf-s are handled by the codes of my mod and another mod. I will have to look further into this once I get the time.

To explain my current speculation, some technical context;

• A ByteBuf, as the name suggests, is a "byte buffer". It represents a byte array allocated somewhere on the device's RAM. They are commonly used when software deals with binary data. The game's and mods' networking codebases too, often use byte buffers.
• Given a ByteBuf allocates a chunk RAM, said RAM needs to be "released" once the buffer is no longer needed. Not releasing the buffer results in a memory leak (because you then have junk occupying RAM).
• One catch about releasing ByteBufs is, if you attempt to release a buffer that's already been released, the buffer throws a refCnt: 0 error. So before releasing such buffers, it's usually a good idea to first check if it was already released.

Now onto my mod's code. My mod, specifically when dealing with some network and packet related aspects, has to handle buffers and on some occasions even create new buffers, all so it can work with binary data and server/client data exchange as it handles networking packets.
As explained above, to avoid memory leaks, my mod has to release the buffers it dealt with, to avoid any memory leaks (I believe this behavior is coming from TCDCommons, as that mod of mine is the one that has a bunch of networking code).
And yes, I do in my mods's code make refCnt checks to ensure buffers weren't released prior to releasing them.

Now my speculation is that mayhaps another mod that also deals with networking code, also just so happens to hold a reference to one of the netowrking buffers, and in an assumption nothing else released them, they attempt to release said buffers, causing the refCnt error. So in other words;

1. My mod uses a buffer to deal with binary data
2. My mod checks if the buffer was released, and if not, it releases it to avoid memory leaks
3. Another mod holding the same buffer, also chooses to release the buffer for the same reason, but with an assumption nothing else already released it
4. The refCnt error is thrown.

In other words, my speculation boils down to a conflict in mod behaviors. And the reason I speculate it could be another mod is because this doesn't appear to happen in vanilla instances (by vanilla I mean lack of other mods's presence).

Now if this speculation is true, you may ask "Well, can you just, not release the buffer yourself on your end?", to wich I say;

• "No, it's too risky to let the buffer be. I do not and cannot know if another mod will release the buffer for me, so ignoring it will certainly cause a memory leak if there isn't anything else out there to release it."

At least, that's my best guess. I may look further into this once I get the time. Although, I am hoping a future update I make will fix this issue. As for other mod developers, I'd ask them to make refCnt checks before releasing buffers.