Joshua Edwards

My server (1.14 and then later 1.14.1 Pre-2) has had this issue with all kinds of Entities (Item Frames, Minecarts, Armour Stands, Villagers)

It seems to be based on the chunk? Whereby all Entities in the chunk disappear upon loading the server, as I had Item Frames on two very different Y coords in the same chunk as well as Armour Stands (again in the same chunk) all disappear at the same time.

 
EDIT: Just happened again, does indeed seem to be chunk based (all item frames in the right hand chunk vanished, while the ones on the right did not)

This effects version 1.14.1 Pre-Release 1. Crops no longer pop off the farmland when light level is reduced below the threshold. (See attachments "2019-05-08_10.03.00.png", "2019-05-08_10.03.05.png" and "2019-05-08_10.13.37.png")

I'll add that any redstone/block changes in the affected area also causes it. So redstone dust, repeaters, pistons, etc. It's pretty unplayable with any sort of fast redstone clock

@Marcono1234, I can report that, sure. I'm curious though as to the nature of why memory built up as a result of using negative integers. Is there a check on the client's end for this? What's actually going on? I'm still seeing a memory leak as a cause of this. I don't expect a leak (even with improper data values for IDs), as a purposeful design. The same goes with the CommandBlock API.

Thanks.

@Marcono1234, Was that test case of any use?

Marcono1234, https://github.com/JabJabJab/Minecraft-1.13.2-ItemFrame-MemoryLeakTest/releases/tag/1.0

This has two tests. use "/test 1" for the positive map test. Use "/test 2" for the negative map test. Test 2 has working map data, unlike the command block API test which simply shows the leak occurs. Use "/test stop" to clean up the test. The test uses the world coordinate "180 70 60" to perform the test. This coordinate and the dimensions used to perform the test are located in "Test.java".

Apologies for the delay, however I did spend time cleaning up the code so it functions without errors, is completely legible code, and a lot of unused code was pruned.

I will release my code. I had to take care of things and should get it in the next 24-48 hours. Apologies for the delay.

@Marcono1234 I used Spigot to perform the test. I will clean it up and upload it to GitHub sometime today, linking it here.

@Pokechu22 Thank you for taking a look. negative map IDs worked before 1.13 as the short values for map IDs were damage values for the item stacks. In 1.13, the ItemStack NBT tag data stores it as an integer.

I'm guessing there's some internal storage for the maps that's based off of a positive number, and when a negative map is rastered on an ItemFrame, Minecraft solves this by creating a new map. I haven't taken a closer look, however that's the most sense I can make with this. It sounds like Minecraft has some kind of system to correct negative map numbers, and it's probably not working as intended. The reason why I'm guessing this is due to the fact that my server's world folder had a ton of map data files in the /data/ folder.

The latest world zip folder has the command API setup and ready to test, however you can take the lines and make one yourself. I'm glad that I can get around this bug. I thought it was something much worse that I couldn't simply avoid.

I have tested further with the negative IDs using the existing commandblock API test, modified to use negative map IDs. This causes the client-side memory leak, independent of any server-side modification.

^{The command block commands I used are:}

CLEAR:

kill @e[type=minecraft:item_frame,x=180,y=70,z=60,dx=16,dy=9,dz=1]
fill 180 70 55 196 79 62 minecraft:air

CREATE:

fill 180 70 60 196 79 60 minecraft:stone
fill 180 70 59 196 79 59 minecraft:command_block{Command:"summon minecraft:item_frame ~0 ~0 ~2 {Facing:3,Item:{id:\"minecraft:filled_map\",tag:{map:1}}}"}
fill 180 70 58 196 79 58 minecraft:redstone_block
fill 180 70 56 196 79 56 minecraft:command_block{Command:"data merge entity @e[type=minecraft:item_frame,limit=1,dz=5] {Item: {id:\"minecraft:filled_map\", Count:1b, tag:{map:-1}}}"}
fill 180 70 55 196 79 55 minecraft:redstone_block
fill 180 70 59 196 79 59 minecraft:air
fill 180 70 59 196 79 59 minecraft:command_block{Command:"data merge entity @e[type=minecraft:item_frame,limit=1,dz=2] {Item: {id:\"minecraft:filled_map\", Count:1b, tag:{map:-2}}}"}

LOOP:

1

fill 180 70 58 196 79 58 minecraft:air
fill 180 70 55 196 79 55 minecraft:redstone_block

2

fill 180 70 55 196 79 55 minecraft:air
fill 180 70 58 196 79 58 minecraft:redstone_block

I have done more testing writing a test-case using Spigot's plug-in API. I have tested using ONLY the basic API for Spigot and found no leaks.

I have also included the packets that I have sent to the player manually using the NMS API, and I did find out what exactly is causing this memory leak. It's due to negative Map ID's. If I set my map IDs to negative and constantly cycle ImageFrames, The client-side memory allocation goes up very quickly. (16x9 frames cycling every half second between 2 maps) If I set the map IDs to a positive integer, the memory leak vanishes.

I can package up the plug-in code as a test-case on GitHub, however it seems to be directly caused by negative ID's.

I took the time to implement this same effect using only command blocks. The memory leak does not occur. I feel like this could be an issue with the way information is sent to the client for changing the information. If I find that it is an issue with an unchecked variable with the metadata packet sent to the item frames, I'll post an update here because the client can still leak memory really bad from the original method used that still causes a leak.

^{The button on the far right clears the board entirely. The one to the left creates it, and the lever toggles the loop to cycle map changes.}

I have no issue creating a test-case plugin, or exploring the command API to see if this is capable of being reproduced in more than one way.