The bug
This is a rendering bug to do with Tile Entities in a chunk. I have provided screenshots which aim to show how to reproduce too.
If you have 64 or more Tile Entities within the same chunk and then "delete" them, using either /fill
, /clone
or (if they are signs) retracting them using pistons, when you place a new Tile Entity in that same spot, the previous Tile Entity will render over that or instead of the new Tile Entity.
For example, if you have a wall of 64 chests, do /fill
to get rid of them and then place a beacon down where one chest was, you'll get a chest that's rendered inside a beacon. If you place a sign down you get an error that says "Unable to locate sign".
All rendering errors and effects are cleared with a relog, so perhaps this has something to do with the way chunks are updated or saved?
How to reproduce
Press
F3
+G
to make sure the blocks you are filling are in the same chunkUse for example the
/fill
command to place 64 or more tile entities/fill ~1 ~ ~ ~5 ~4 ~4 enchanting_table
Use for example the
/fill
command again to replace these tile entities with different tile entities/fill ~1 ~ ~ ~5 ~4 ~4 ender_chest
Code analysis
Code analysis by @unknown can be found in this comment.
Related issues
is duplicated by
relates to
Attachments
Comments

Another thing that happens here is if you replace some written signs with air, the text of the old sign shows up at the gui "edit sign message" where you can enter the text for the sign. You can delete it there but if you leave it, it will show up even after a reload as you've written it.

Actually, this is /fill command not doing its job right. Fill command doesn't destroy old tile entities, just their blocks and since MC has custom renderers for some tile entities, old renderer remains.
As old tile entity remains in the same place and when placing another you create a new one, you end up with two tile entities in the same place and a new block which actually opens new GUI.
This is /fill and similar commands not (re)moving tile entities as they are supposed to.
Also, the reason this glitch resets after restarting the world is because Minecraft tries to validate tile entities when they load and see if their block is still there (which fill doesn't) and destroys them if their block doesn't exist.
It is weird however that /fill does work below 63. This is probably another bug that has to do with chunk update inconsistencies.

Confirmed for 15w49b

Confirmed for 15w50a

Confirmed for 15w51a & 15w51b.

Confirmed for 1.9 Prerelease 3.

Confirmed for 1.9 Prerelease 4.

Confirmed for
1.9.1-pre3

Please link to this comment in the description
The following is based on decompiled version of Minecraft 1.9 using MCP 9.24 beta. All method and class names are the names used in the decompiled version.
The reason for this is very likely that the method net.minecraft.world.chunk.Chunk.fillChunk(PacketBuffer, int, boolean)
is modifying the net.minecraft.world.chunk.Chunk.storageArrays
directly. This means it does not test if the block which is changed is a tile entity or if a tile entity exists at this position already.
Unless a new tile entity is created for this position and the according packet is send to the client the client will not create the tile entity. This means that any non-tile entity will cause this as well as some tile entities that do not override net.minecraft.tileentity.TileEntity.getDescriptionPacket()
like for example enchanting tables (this causes them to have no books).
Can confirm for MC 1.12.1.

sa bug sa me soule je vien juste de l avoir

Also happens in 18w06a. Gets fixed upon chunk reload. Filling Ender Chests into Enchantment tables also caused the following crash:
[media]

Please create a separate ticket for your crash.