Object update message is, rarely, too long.
tracked
animats Resident
Most ObjectUpdate messages are fine, but after several hours of running, I got a few that were one byte oversize. and one that was 12 bytes oversize.. This is message number 0xc, or High 12 in SL message number form.
My experimental Sharpview is picky about this - such messages are discarded. Dropping these may be causing another problem for Sharpview, but it's too soon to tell.
The size comes from the message template. Message template is from https://github.com/secondlife/master-message-template/blob/master/message_template.msg
This seems to be new. I haven't seen wrongly sized messages on the main grid much in years. This was detected in the test regions running Riders Test Channel 2026-09-16.35125851769.
Log In
Monty Brandenberg
> Is there some new code path that generates object update messages?
While it's not called out in the release notes, there is a change of particular interest to anyone implementing their own message parsing. Some work was done on the "ZeroCoded" compressor which can affect any templated message tagged with the encoding. We're looking at this right now but this is an area you may want to watch closely.
animats Resident
Monty Brandenberg Hm.
That this is a zerocoding problem seems reasonable, since one of the messages I logged as having the wrong length ended with 12 bytes of zeroes. No zerocoded message should contain 12 successive bytes of zeroes.
Here's my zero decoder. The algorithm is just:
/// Each zero is converted to N zeroes, using the next byte as a count. [0 1] means one zero.
My Rust code is here: See "decodezerocodedyn" and "decodezerocodestat" in:
The comparable LL code is at
with the comment
// Runs of zero bytes in the body are replaced by a two-byte token:
// 0x00 N - represents N zero bytes, for N in 1..254
// 0x00 0x00 N - represents (255 + N) zero bytes (wrap/overflow case,
// produced by decode()'s wire format but never emitted
// by encode(), which instead starts a fresh 0x00 token
// every 255 zero bytes)
That seems to define a form for a very long run of zeroes expressed as [0 0 N]. but says it is not used by "encode". I treat a [0 0] as an error to log, and I'm not seeing that in my logs.
Git blame shows that code being recently moved to a header file: https://github.com/secondlife/viewer/blob/bd9990e3db5c6400e2c7fa26651167fc43e1ee37/indra/llmessage/llzerocode.h
Here's the LL pull request, from August 2026:
No big insight yet, but I'll look a bit more.
Monty Brandenberg
animats Resident: Viewer received the same ZC change and we have found an issue which we're working on. I know you can't see it but for reference purposes, this is server#2762.
A viewer GHI will be along shortly which you should be able to inspect.
While it's early, we hope to refresh BlueSteel with a fix and we'll say more when that happens.
animats Resident
Monty Brandenberg Ah, good. Leviathan just brought this up at Server User Group, and says there's a fix pending.
Monty Brandenberg
animats Resident: RC BlueSteel just finished rolling. (Other rolls still underway.)
Monty Brandenberg
Thanks. We see the extra data.
Maestro Linden
updated the status to
tracked
Maestro Linden
Thanks for the report animats Resident. I see some logRanOffEndOfPacket warnings as well in my own viewer log. It seems that simply going to a new region triggers a handful of the problematic ObjectUpdate messages.
animats Resident
Maestro Linden Ah, it's reproduceable. Always good.
A handful of messages is about right. This is a rare event.
This is in the simulator with Pepper Linden's new region crossing fixes, so it makes sense that it might appear associated with region crossings. In my own Sharpview viewer, the avatar fails to cross regions around the same time this error is logged, and things go downhill from there. When I get an off-sized message in Sharpview, I log and drop it, so I'm probably dropping the object update that caused the avatar to enter a new region. Does the LL viewer drop those, or log and continue?
Sharpview sees a DisableSimulator message about 50 seconds later, which I previously thought was a bug, but I now suspect is a consequence of losing an ObjectUpdate and the avatar not entering a region.
I just checked, and the message template I'm using matches the current version in the LL viewer for ObjectUpdate.
Maestro Linden
animats Resident: I'm also able to reproduce it on certain regions running https://releasenotes.secondlife.com/simulator/2026-09-14.34880154149.html as well - I think the region-crossing-changes simulator on aditi inherited the bug from that release.
We think it's related to ObjectUpdate messages containing unicode, but are not quite sure which field is responsible. I haven't encountered a DisableSimulator event proceeding logRanOffEndOfPacket with the SL viewer - it seems like the viewer remains connected to the sim. I suspect the viewer drops the ObjectUpdate message it can't decode, which would mean the viewer would show a stale version of the object or not render it at all.
animats Resident
Maestro Linden That makes sense.
When I detect this with Sharpview on the aditi test regions, it's after hours of a test avatar riding on a little train around a track loop that goes right through a region corner. It's a test track I built to detect rare failures. So I'm detecting a rare bug with a very picky viewer using a long term test. It still takes hours to get a failure, at about four region crossings per minute.
If the same bug was already present on the agni main grid, I wouldn't notice, because the normal failure rate for region crossings is maybe 1-2%. So it's quite possible this bug went in long before Pepper's fixes.
Re:
We think it's related to ObjectUpdate messages containing unicode, but are not quite sure which field is responsible.
If you're stuck on that, I could modify Sharpview to try formatting the overly long packet with my formatted packet dumper.animats Resident
There's more detailed info in the report, but Canny is suppressing the rest of the fields.