After checking the source code of the v1.14.7 I see that the problem comes from having an order limit that’s exceed the maximum value of an int32 but I cannot say if a valid order limit can have a size above that value or that happens because there is an invalid/malformed order limit.
The crash comes from https://github.com/storj/storj/blob/e3b8c02b58c90962c3baad410f50a44b64684cb3/storagenode/orders/store.go#L536
In that line a new slice is made and the length of it is set by the above line with limitSize := binary.LittleEndian.Uint32(sizeBytes[:])
What happens there is that Go int type can be 32 or 64 bits depending of the architecture and OS and in your case I’m assuming that’s 32 because despite is a Raspberry Pi4, which is a 64 bits architecture, it’s running a 32 bits OS.
Then when the value a greater value from the max int32 the limitSize variable, which is of uint32 get passed to make builtin function whose second parameter of the type int and that’s when it got coerced to a negative int32, making the make function to panic with panic: runtime error: makeslice: len out of range.
Following the stack trace, the call to readLimitAndOrder (that’s the function that panics) comes from the ListUnsentBySatellite (https://github.com/storj/storj/tree/https://github.com/storj/storj/blob/e3b8c02b58c90962c3baad410f50a44b64684cb3/storagenode/orders/store.go#L242).
We could add a check for limitSize and return if the value gets negative when coercing to int but it turns that we have had some refactorings on such code that may have solved the problem and they are already merged into master.
- https://github.com/storj/storj/commit/fbf2c0b242af768ee5c81b2b4eab8fde57f6cba0
- https://github.com/storj/storj/commit/02cbf1e72a3be1a3d81543c122d299d154a5135c
They are tagged on the v1.15.1 so I expect them to be in the next official release but I’m going to make sure that they get into.