mojira.dev
MCPE-175988

Array NBT comparison fails after converting to BinaryNBT and back.

Both classes ByteArrayTag and IntArrayTag use TagMemoryChunk to store data. The virtual function equals in both classes uses memcmp to compare whether the two data are equal.
The problem is that the strange naming of members in TagMemoryChunk makes it easy to make mistakes when using it. mElement is the number of elements, mSize is the capacity of the buffer, usually we use mSize, mCapacity instead of the former.

Element * sizeof(byte or int) (depending on the type of storage) is always less than or equal to mSize. when comparing two memoryChunks, you should compare the element * sizeof number of data, not the mSize number of data.

In BinaryNBT and NetworkNBT parsing, the mSize of the requested memorychunk is usually larger than the actual size, and those parts are uninitialized, which leads to the possibility that two identical nbt's may output false when calling equals.

Steps to Reproduce:
1. Create an NBT with a ByteArrayTag or IntArrayTag,
2. convert it to a BinaryNBT, then convert it back to an NBT, and
3. compare it to the previous NBT.

Observed Results:
High probability of outputting false (because the tail is not initialized).

Expected Results:
always true.  

Solution: Use memcmp in the equals function of these two classes to compare the length of mElement * sizeof, not mSize.

Comments 4

Can you please be more specific about how to reproduce this with in-game steps?

@tryashtar This is a logic bug in the bedrock source code, which needs to be confirmed by mojang staff testing themselves. This is not a specific game runtime bug, but may affect all places where you need to check if two nbt's are equal, including subsequent game development.

Without a way to verify the issue, I'm afraid it's unlikely the ticket can be confirmed and subsequently addressed

In 1.20.60, the TagMemoryChunk that was causing the problem was removed in favor of a safe std::vector, and this bug has been fixed.

ΘΣΦΓΥΔΝ

(Unassigned)

Unconfirmed

Multiple

1.20.50.20 Preview, 1.20.32 Hotfix

Retrieved