Minecraft Version

1.21.x

Version

1.114.2

Details

Versions:

• Minecraft 1.21.1
• NeoForge 21.1.93
• CC: Tweaked 1.114.2

Confirmed that 1.20.1 branch does not have this issue

Bug

There seems to be a direct-memory leak (off-heap) in Monitor network status packet handling. Given the reproduction below, every so often, the Direct Memory used by Minecraft will increment up by 4MB, until it results in an OOM.

Reproduction (Tested only in Singleplayer)

1. Load up a world and add some monitors to a peripheral network. Connect a computer to the network.
   • It's unclear if the number of monitors has an effect, but in my testing it seems that the memory leak is sped up
2. pastebin get vpEPf1kE leaky.lua
3. leaky.lua
4. Observe occasional memory increments of 4MB in Task Manager, every few minutes or so.
   • This is most easily seen by letting the computer run for a while and coming back to see the memory usage has increased

The leak can also be detected via jconsole (should be installed if Java JDK is installed)

1. Open command prompt and run jconsole
2. Open a new connection to the JVM running Minecraft
3. Navigate to MBeans > java.nio > BufferPool > direct > Attributes
4. Note the MemoryUsed stat.
5. Run leaky.lua
6. Note the increase in memory used in 4MB increments over time, and the general increase in buffer counts.
7. Note that leaving the game/terminating the CC computer does not release the memory
8. Given enough time, the game will give an OOM error.

The OOM error can be forced to occur sooner by setting this launch arg -XX:MaxDirectMemorySize=64M or similar number

EDIT: Repeating the above on the 1.20.1 branch shows many more direct buffer allocations, but they are all cleaned up correctly. I have been unable to reproduce the issue in the 1.20.1 branch

EDIT 2:
Launch the game with the launch arg -Dio.netty.leakDetection.level=ADVANCED and run leaky.lua, which spams the console with netty memory leaks.

Workaround

Add the following launch arg to minecraft: -Dio.netty.allocator.type=unpooled

Logs

Upon OOM'ing, this is the log that gets generated with -XX:MaxDirectMemorySize=128M:
latest.log
debug.log
disconnect-2025-01-11_19.21.28-client.txt
The game does not crash, so no crash report is generated.

According to the error log, at least one of the allocations happens at dan200.computercraft.shared.computer.terminal.TerminalState.<init>(TerminalState.java:50)
Link

Sidenote: The memory amount it tries to reserve is 4194304 bytes which is exactly 2^22

A world download can be supplied if not able to reproduce.

Lua code

-- Connect a few monitors, open up task manager, run this program, and wait.
-- Note that the memory used goes up in 4MB increments every so often,
--   but the in-game F3 menu does not show any memory increase.
-- The memory is not released until the game is closed.
local periphs = peripheral.getNames()
local windows = {}

for _, periph in pairs(periphs) do
    if peripheral.getType(periph) == "monitor" then
        local mon = peripheral.wrap(periph)
        local sizex, sizey = mon.getSize()
        local win = window.create(mon, 1, 1, sizex, sizey)
        table.insert(windows, win)
    end
end

while true do
    -- os.queueEvent("er")
    -- os.pullEvent("er")
    os.sleep(0)  -- Replace this line with the 2 above to maybe make the leak happen quicker if not seeing it.
    for _, win in pairs(windows) do
        win.setVisible(false)
        win.clear()
        local old = term.redirect(win)
        local sizex, sizey = win.getSize()
        paintutils.drawFilledBox(1, 1, sizex, sizey, colors.orange)
        term.redirect(old)
        win.setVisible(true) -- It seems commenting out this line prevents the issue
    end
end

@Kasra-G can you try replace setVisible(true) to redraw()?
and remove setVisible(false)

@Kasra-G can you try replace setVisible(true) to redraw()? and remove setVisible(false)

Still observing the leak

Thanks for the report! The issue is definitely in the Java side, so changing the Lua code won't have any effect here.

A lot changed in Minecraft's networking code between 1.20.1 and 1.21.1, so it's hard to know quite what introduced this. I think it's going to be easier to just rip out this code and replace it with a normal byte[].

Thanks for the fix. Speculating from the number of direct buffer allocations, I would guess that in 1.20.1 there was no pooling behavior for the direct buffers. From jconsole, each tick, the number of buffers increases but is eventually GC'd.

With 1.21.1 there seems to be a pooling behavior - 4MB is the default netty arena chunk size, and we only see a few large direct buffer allocations in jconsole. Once a chunk fills it has to allocate a new 4MB chunk to reserve from.

I believe with pooling enabled, .release() needs to be called on any ByteBuf before garbage collection to return that chunk of the direct buffer back to the pool.

still speculation of course, since I do not know the specifics of the networking changes between 1.20 and 1.21

Edit:
Confirming that running on 1.21.1 with the launch arg -Dio.netty.allocator.type=unpooled is a valid workaround