added real bounds checking to ByteString.Slice
#6709
Conversation
Fixed a very weird bit of code that could result in byte buffers constantly allocating despite being of illegal size.
| @@ -57,8 +60,10 @@ public void A_ByteString_must_be_sequential_when_slicing_from_start() | |||
| [Fact] | |||
| public void A_ByteString_must_be_sequential_when_slicing_from_index() | |||
| { | |||
| Prop.ForAll((ByteString a, ByteString b) => (a + b).Slice(a.Count).SequenceEqual(b)) | |||
There was a problem hiding this comment.
Some of these property-based tests no longer pass because, as should be no surprise, the ByteString.Slice method will no longer work with arbitrary index and count values - hence why certain random-generated values fail during testing now.
| public ByteString Slice(int index, int count) | ||
| { | ||
| //TODO: this is really stupid, but previous impl didn't throw if arguments |
There was a problem hiding this comment.
@Horusiath 's comment here was the first sign that there was something weird going on inside this method, when I started investigating how our Petabridge.Cmd code could run out of memory. Sure enough - this method will produce arbitrary byte arrays regardless of what the index and count values are, which caused our looping mechanism for decoding messages to go haywire.
If someone is depending on this old behavior - sorry, but that's your problem now - we're going back to byte arrays meaning what they mean starting in Akka.NET V1.5.
|
My ideal solution to this issue is #6708 - but that's going to need to wait until Akka.NET v1.6 most likely. We'll need to get rid of |
Changes
Fixed a very weird bit of code that could result in byte buffers constantly allocating despite being of illegal size. This caused parts of Petabridge.Cmd's Akka.IO message decoding to run out of memory during message decoding.
Checklist
For significant changes, please ensure that the following have been completed (delete if not relevant):