Alright, I'm a bit stumped on this.
Except for some IBlockState<->NBT handling, I'm not doing anything that I haven't done before, without issues.

To clarify the issue: Minecraft suspends (freezes completely) whenever I do either of 2 things in my project:
Using the ItemCompressionWand on a proper Multiblock structure,

And when getPickBlock is called in CompressedBlock, when a Creative player scroll-wheel-clicks on a block, that was previously placed by the mentioned ItemCompressionWand.

 

The suspension happens in AnvilChunkLoader#writeNextIO(), Line 242 (the finally block)

 

Except for a pure java crash, that only happened once, there are no crashlogs.

 

Latest log

Latest Client log

I am using Forge 1.10.2-12.18.2.2123

Further investigation:
Issue is a StackOverflow error, in the mentioned AnvilChunkLoader#writeNextIO().

I have traced it down to only the getPickBlock() method now.

 

Is there an issue with using TileEntity#getTileData()? I am literally only copying tags from that to the ItemStack that was gained from super.getPickBlock().

Yeah, missed a null check there, but that should have given me a nullpointerexception, no? Not a stackoverflow.
 

I was storing the data inside TileEntity::getTileData(), as seen here.
As such, the wanted data should have been accessible from that NBTTagCompound.

 

I am now, no longer using TileEntity::getTileData(), but storing the NBT data in the proper fashion. After the switch, I have not gotten another suspension.
However, even when overriding TileEntity::getUpdatePacket() & TileEntity::onDataPacket(), the state field always returns null on the client, after re-launching. I've even tried using custom Packets to forcefully update the client Tile with the Server Tile's state, yet nothing seems to stick.

To note, the state is required immediately on the client, as the state is required to render the proper model.

Spoiler

[11:28:12] [Server thread/INFO] [STDOUT]: [se.Matryoshika.Echo.Common.Content.Tile.TileMenger:readPacketNBT:58]: State is: minecraft:emerald_block
[11:28:13] [Client thread/INFO] [STDOUT]: [se.Matryoshika.Echo.Common.Content.Tile.TileMenger:readPacketNBT:58]: State is: minecraft:air

One thing I've noticed, is that TileEntity::getUpdatePacket() is only invoked when the Tile is placed, not when the Tile is rebuilt from NBT. Doesn't that defy the purpose of syncing Server->Client with TileEntity::getUpdatePacket() & TileEntity::onDataPacket() though?

2 minutes ago, diesieben07 said:

This won't work. A TileEntity must have a public no-argument constructor.

Ah, sorry, outdated code.
GitHub has been updated now.

NBT syncing has been fixed.
Had to override TileEntity::getUpdateTag & TileEntity::handleUpdateTag as well.

14 hours ago, Matryoshika said:

Issue is a StackOverflow error,

StackOverflow suggests accidental recursion. I ran into that myself with tile entities. Some of their methods are non-intuitive, making it possible to fall into a recursion trap. If you encounter StackOverflow again, step through TE construction to see what methods get involved when. You might then see an unexpected call that leads to recursion.