[script:sessionmanage] RangeError: index out of range: 14 + 4 > 15

valkodagon · November 17, 2023, 3:16pm

In our live server, we are experiencing this error every restart. Sometimes it happens within the first 5 minutes or sometimes a few hours, it’s unknown exactly what the cause is but I’m reporting it so hopefully the team can fix it.

Any idea what happens to the server when this error occurs? Does the session manager fail at this point?

Some parts of the stacktrace have been redacted to hide the server specifics.

[script:sessionmanage] [script:sessionmanage] [script:sessionmanage] [script:sessionmanage] [script:sessionmanage] [script:sessionmanage] [script:sessionmanage] [script:sessionmanage] [script:sessionmanage] [script:sessionmanage] [script:sessionmanage] [script:sessionmanage] [script:sessionmanage] [script:sessionmanage] [script:sessionmanage] [script:sessionmanage] [script:sessionmanage] [script:sessionmanage] [script:sessionmanage] [script:sessionmanage] [script:sessionmanage] [script:sessionmanage] RangeError: index out of range: 14 + 4 > 15
at indexOutOfRange (\server\resources[CFX][system]\sessionmanager-rdr3\node_modules@citizenfx\protobufjs\src\reader.js:13:12)
at Reader.read_float [as float] (***********\server\resources[CFX][system]\sessionmanager-rdr3\node_modules@citizenfx\protobufjs\src\reader.js:272:15)
at Type.TransitionToSession_Parameters$decode [as decode] (eval at Codegen **\server\resources[CFX][system]\sessionmanager-rdr3\node_modules@protobufjs\codegen\index.js:1:1), :14:9)
at Object.TransitionToSession (@sessionmanager-rdr3/sm_server.js:186:47)
at handleMessage (@sessionmanager-rdr3/sm_server.js:303:33)
at @sessionmanager-rdr3/sm_server.js:314:27
at citizen:/scripting/v8/main.js:477:30
at Number.__cfx_wrap_1479 (citizen:/scripting/v8/main.js:23:12)
at citizen:/scripting/v8/main.js:29:16
at citizen:/scripting/v8/main.js:450:3
RangeError: index out of range: 14 + 4 > 15
at indexOutOfRange (\server\resources[CFX][system]\sessionmanager-rdr3\node_modules@citizenfx\protobufjs\src\reader.js:13:12)
at Reader.read_float [as float] (\server\resources[CFX][system]\sessionmanager-rdr3\node_modules@citizenfx\protobufjs\src\reader.js:272:15)
at Type.TransitionToSession_Parameters$decode [as decode] (eval at Codegen (***********\server\resources[CFX][system]\sessionmanager-rdr3\node_modules@protobufjs\codegen\index.js:1:1), :14:9)
at Object.TransitionToSession (@sessionmanager-rdr3/sm_server.js:186:47)
at handleMessage (@sessionmanager-rdr3/sm_server.js:303:33)
at @sessionmanager-rdr3/sm_server.js:314:27
at citizen:/scripting/v8/main.js:477:30
at Number.__cfx_wrap_1479 (citizen:/scripting/v8/main.js:23:12)
at citizen:/scripting/v8/main.js:29:16
at citizen:/scripting/v8/main.js:450:3

d22tny · November 20, 2023, 8:59pm

d22tny · November 20, 2023, 11:04pm

I do experience the same problem on my server, i don’t know if it’s related to this but i have some players that sometimes get pulled into a solo session and can’t be solved until relog.

Disquse · January 8, 2024, 12:19pm

This is not related to OneSync.

valkodagon · January 9, 2024, 12:46am

It kind of is but isn’t at the same time, the root cause comes from the use of protobuf.js which is used by the cfx server resources and utilized for packaging and unpacking data for the session. The root cause is a bug in protobuf.js and it can be best described here:

github.com/protobufjs/protobuf.js

Reader.read_uint32 causes reader head misalignment when consuming oversized VARINTs in some cases

opened 09:59PM - 23 Nov 23 UTC

SimplyLinn

protobuf.js version: latest master I'm looking into reading a uint32 value di…rectly from a without instantiating a reader, and I was looking at this official implementation for reference, and [this section](https://github.com/protobufjs/protobuf.js/blob/4436cc748c19b88977ab0dc84e59c42339e00520/src/reader.js#L95-L99) stumped me a little. I ended up digging through some documentation and playing with the implementation a bit, and I think what it does is that, if the last byte of the uint32 has the "has more data"-bit set, we assume it's a uint64, and consume those bytes as well. The potential issue I've picked up on is if it's not a full 10-byte VARINT, but, say a 6, 7, 8 or 9 byte VARINT. The actual numerical data in that case only takes between 6 and 9 bytes, but the reader unconditionally consumes the full 10, leaving the reader position-head in a misaligned position. ```js import protobuf from 'protobufjs'; function example1() { const writer = protobuf.Writer.create(); writer.uint64((2n ** 53n - 1n).toString()); writer.uint32(42069); writer.uint32(42069); const arr = writer.finish(); console.log( '~~Example 1: uint64 write is 8 bytes long~~\nUint8Array Length:', arr.length, ); const reader = protobuf.Reader.create(arr); try { console.log('First uint32 read:', reader.uint32()); } catch (err) { console.error('First uint32 read error:', err.message); } try { console.log('Second uint32 read:', reader.uint32()); } catch (err) { console.log('Second uint32 read error:', err.message); } try { console.log('Third uint32 read:', reader.uint32()); } catch (err) { console.log('Third uint32 read error:', err.message); } } function example2() { const writer = protobuf.Writer.create(); writer.uint64((2n ** 64n - 1n).toString()); writer.uint32(42069); writer.uint32(42069); const arr = writer.finish(); console.log( '\n~~Example 2: uint64 write is 10 bytes long~~\nUint8Array Length', arr.length, ); const reader = protobuf.Reader.create(arr); try { console.log('First uint32 read:', reader.uint32()); } catch (err) { console.error('First uint32 read error:', err.message); } try { console.log('Second uint32 read:', reader.uint32()); } catch (err) { console.log('Second uint32 read error:', err.message); } try { console.log('Third uint32 read:', reader.uint32()); } catch (err) { console.log('Third uint32 read error:', err.message); } } example1(); example2(); ``` ``` ~~Example 1: uint64 write is 8 bytes long~~ Uint8Array Length: 14 First uint32 read: 4294967295 Second uint32 read: 2 Third uint32 read: 42069 ~~Example 2: uint64 write is 10 bytes long~~ Uint8Array Length 16 First uint32 read: 4294967295 Second uint32 read: 42069 Third uint32 read: 42069 ``` I created an example to demonstrate the inconsistency, notice how the second uint32 read of example 1 is wildly wrong because parts of it was already naively consumed by the code I highlighted in my description. In example 2, the written uint64 takes up the assumed 10 bytes and the head ends up correctly aligned for the second uint32 read. In this trivial case, the read-head rediscovers the value boundaries and the value of the next read was just slightly wrong, but the misalignment could cause a lot more weirdness should the next data be something else. The decision of whether the reader should throw an error if the VARINT is oversized, or if a more robust "end of VARINT" check should be performed to find the actual boundary of the value I leave to the maintainers.

The user describes how the position head can be calculated wrong depending on if the VARINT is a full 10 bytes or not. If this issue is resolved in protobuf it would be a really good improvement for the CFX session manager resource to point to the latest version of protobuf and rebuild/redistribute over NPM.

In the meantime, if someone can figure out how to fix that section of code and send us all the change please do!