Tried several times to read chunk -5,-137. Unknown error. Giving up

[MikeyCarter]

How do I debug if this is a bug or actual corruption. Only started to come up with 1.8.1.

[MikeyCarter]

Went looking for chunk -5, -137. I have a feeling I know what it is. I have a command block which has a /give book. The command block has 40153 bytes.

It throws a [Netty Epoll Server IO #9/ERROR]: io.netty.handler.codec.EncoderException: String too big (was 40153 bytes encoded, max 32767) error but works fine. I have a feeling it's this command block throwing your corruption problem.

[MikeyCarter]

Confirmed. Seems if you have a command block with a lot of text in it your overview has troubles reading the chunk.

[CounterPillow]

The NBT format uses a signed short to indicate the length of a string, which has a maximum upper value of 32767. I'm not exactly sure how Minecraft even stores the big command block.

[MikeyCarter]

Interesting. It does allow it as my string at the time was 40153 bytes. Any case I've redesigned my menu book to use the chat window instead so I can work around this.

[eminence]

Very interesting indeed! Nice debugging. I'm guessing it's a Minecraft bug that it even allowed a command block string of this length. Since this isn't an Overviewer issue, I'm closing this, but feel free to continue to discuss.

[MikeyCarter]

Actually logged a minecraft bug on it. Basically said it's an Overviewer bug. Well no worries can get around the issue.

[eminence]

When you filed the Minecraft bug, did you let them know about the EncoderException you saw?

[CounterPillow]

Additional notes from Tunabrain related to the issue, made on IRC:

[10:28] <Tunabrain> Like recently when it turns out that Mojang writes unsigned length specifiers for strings, even though the spec says signed
[10:29] <Tunabrain> Sooo there was of course a string in the NBT with 55k characters that would read as length -9000 if you interpreted it according to the spec, and the entire thing thrashed itself to bits

Issue should be re-opened. Mojang may have buggered up their own format, but we still have to treat it right, i.e. read an unsigned short instead of signed.

[tunabrain]

Can confirm. It seems that string lengths are interpreted as unsigned shorts. At least, NBT that doesn't parse correctly under the spec will work if you change string lengths to unsigned.

I'm not sure whether this also applies to byte/int arrays, but I doubt Minecraft stores data large enough to run into that issue.

[agrif]

I've changed our NBT parser to use unsigned values for all array lengths, which ought to solve this issue. I'd close it, but... seems it's already closed. 😄