ByteData get* functions don't throw on invalid access when compiled into an exe

[dan-m-moore]

Dart Info
- Dart 3.5.3 (stable) (Wed Sep 11 16:22:47 2024 +0000) on "macos_arm64"
- on macos / Version 14.5 (Build 23F79)
- locale is en-US

I'm writing a Flutter app and noticed a difference in dart SDK behavior between Debug and Release builds, so I investigated with a pure dart example:

import 'dart:typed_data';

void main(List<String> arguments) {
  try {
    List<int> output = [];
    ByteData bytes = Uint8List.fromList(output).buffer.asByteData();
    final _ = bytes.getInt64(0);
    print('caught nothing!');
  } catch (e) {
    print('caught $e!');
  }
}

If I use dart run, this correctly throws an IndexError:

caught RangeError (byteOffset): Index out of range: index should be less than -7: 0!

If I first compile it as an exe dart compile exe bin/test_app.dart -o test_app, then the app happily runs without throwing anything:

caught nothing!

Is this an intentional optimization in the SDK? If so, what's the mechanism that determines whether or not throws are discarded during compilation? I've noticed that other throws within the class survive the compilation, but not the ones for these accessors.

[dart-github-bot]

Summary: The ByteData.get* functions in Dart 3.5.3 do not throw RangeError exceptions when accessing out-of-bounds indices when compiled into an executable, but they do throw in debug mode. The user is asking if this is intentional behavior and what mechanism determines whether exceptions are discarded during compilation.

[julemand101]

I also seem to reproduce the same behavior with:

Dart SDK version: 3.7.0-132.0.dev (dev) (Mon Nov 11 12:03:55 2024 -0800) on "windows_x64"

[julemand101]

Something not so great about this is that it seems like the bounds checking simple does not happens and we allow reading what looks like memory from the heap. I have made a demo program where I was able to use this to extract previous data I have entered in the program.

[alexmarkov]

The problem is that _ByteDataView.getInt64 performs range check against length - 7:

sdk/sdk/lib/_internal/vm/lib/typed_data_patch.dart

Lines 5235 to 5236 in 5dc11bf

	int getInt64(int byteOffset, [Endian endian = Endian.big]) {
	byteOffset = _byteDataByteOffsetCheck(this, byteOffset, length - 7);

length - 7 value is negative if underlying buffer is smaller than 7 bytes (which happens in this example).

_byteDataByteOffsetCheck is recognized by the compiler and generated as a bounds check which performs unsigned comparison of index and length. This bounds check implicitly assumes that checked length is non-negative and doesn't work if it is negative (negative signed value is treated as a very large unsigned value, larger than any non-negative index, so bounds check incorrectly passes).

[lrhn]

Would it be enough to just change , byteOffset , length - 7 to , byteOffset + 7, length? (No, because then it would accept a byte position of -6.)

So maybe , byteOffset, length & -8 (or & ~7, should be the same thing), which rounds down to a multiple of the element size, instead of subtracting it.

[alexmarkov]

@lrhn I don't think rounding would work - we need to check that the whole range [byteOffset, byteOffset+7] is within the bounds. For example, byteOffset could be slightly less than length and length is already a multiple of 8, so byteOffset+7 would be out of bounds.

Fix: https://dart-review.googlesource.com/c/sdk/+/395421.

[lrhn]

Ack, yes, this is ByteData, it allows unaligned access.

Maybe, using arguments of byteOffset , length - size (not length - (size - 1)), the test could be:

if ((byteOffset | (length - byteOffset)) < 0) {
  throw ...
}

That will fail if byteOffset < 0 or if length - size - byteOffset < 0, aka. byteOffset + size > length.