[sldev] Endian bug in 1.15.0.2 message template reader?

[John Hurliman]

Paul TBBle Hampson wrote:
> I'm seeing a problem (posted to the Linux Alpha Client forum [1]) with
> my PowerPC build of the 1.15.0.2 Linux client, which does not happen on
> an AMD64 build of the same source.
>
> Basically, when logging in, I get a bunch of logRanOffEndOfPacket error
> from an ObjectUpdate, followed by the following error:
>
> WARNING: processParcelOverlay: Got parcel overlay size 4 expecting 1024
>
> The significance of the above error is that in 16-bits, 4 byteswaps to
> 1024 (0x0004 => 0x0400). This combined with the fact that it doesn't
> happen on AMD64 is why I think there's a byteswapping bug.
>
> The message template for ParcelOverlay is:
>
> // ParcelOverlay
> // We send N packets per region to the viewer.
> // N = 4, currently.  At 256x256 meter regions, 4x4 meter parcel grid,
> // there are 4096 parcel units per region.  At N = 4, that's 1024 units
> // per packet, allowing 8 bit bytes.
> // sim -> viewer
> // reliable
> {
>     ParcelOverlay Low Trusted Zerocoded
>     {
>         ParcelData      Single
>         {   SequenceID  S32             }   // 0...3, which piece of region
>         {   Data        Variable    2   }   // packed bit-field, (grids*grids)/N
>     }
> }
>
> I guess my first question is, what's that '2' mean? It seems to be
> defined as 'size' during the template reading process, but I've not
> yet been able to work out what it's used for... I'm _hoping_ it turns
> out to be "size will be encoded in a 16-bit word" in which case the
> fix will be as easy as "find the code that reads the size off the
> network, and byteswap it if it's reading anything longer than 1".
>   

According to http://www.libsecondlife.org/wiki/Protocol_%28network%29 
the "Variable 2" means two bytes are used for the 'size' or 'count' of 
that block or field.

"Variable blocks are prepended with either one or two bytes saying how 
many there are. If a block is Variable 2 in the protocol map it uses two 
bytes in big endian format, so a count of 7 would be specified with 0x0700."

The relevant parsing code in libsecondlife is "length = 
(ushort)(bytes[i++] + (bytes[i++] << 8));" so I believe it is a big 
endian value. Second Life might always be byte swapping and not taking 
in to account that things are already correctly ordered on big endian 
platforms, which is why we opted for the endian-agnostic bit-shifting 
technique above (thanks Ben). In the packet you posted above, Data is 
always going to be a 1024 byte field and since you can't specify the 
value 1024 in a single byte it is Variable 2, and the short should look 
like 0x0004 [0 + (4 << 8) = 1024].

> I guess this also assumes that the SL network protocol is little-endian.
>
>   

The page I linked above attempts to describe the endianness of the 
packets. It starts off with:

Big : Big : Little

for the header and then everything in the meat of the packet is little 
except for size identifiers are big and IP addresses are big (even 
though other 32-bit integers are little). I'm actually surprised it took 
this long for a platform-endian issue to crop up.

> Given that Mac OS X runs on PowerPC too, I figured there'd be some
> byteswapping logic for it, but I couldn't find any relevant defines
> in llmessage's source.
>
> I'd also appreciate any other suggestions as to what might be going
> wrong. I'm on the Orientation Island, in case there's something special
> about it.
>
> Interestingly, I didn't have this problem with the 1.14.0.1 build,
> or the 1.14.1.0 build.
>
> [1] http://forums.secondlife.com/showthread.php?t=183218
>
>
>   

I use the SVN source drops put out by the OSLCC project to diff files 
and try to figure out what changed. Now that there is an official 
repository you might be able to use that instead, but I don't know if 
there is enough history in it to catch the change.

John Hurliman