bug: failing MXP Tests

[DavePearce]

Three tests in MxpTest have been @Disabled since they are all failing with this error:

java.lang.IllegalArgumentException: hub.context/RETURN_DATA_OFFSET has invalid value (9223372036854775807)

The value 9223372036854775807 is 0x7FFFFFFFFFFFFFFF and equals Long.MAX_VALUE. For the record, the tests are:

• testMxpRandomTriggerMxpx()
• testRandomMxpInstructionsFollowedByTriggeringRoob()
• testMxpRandomAdvanced()

[DavePearce]

And we begin tracing this back. Problematic value comes from here (OperationAncillaries):

public static MemorySpan outputDataSpan(final MessageFrame frame) {
   
   ...
    
   switch (opCode) {
      case RETURN, REVERT -> {
        long offset = Words.clampedToLong(frame.getStackItem(0));
        long length = Words.clampedToLong(frame.getStackItem(1));
        return MemorySpan.fromStartLength(offset, length);
      }

Which looks to me rather like it was generated from the stack?. Yes, and we can see where our magic Long.MAX_VALUE appears from:

  static long clampedToLong(final Bytes uint) {
    if (uint.size() <= 8) {
      final long result = uint.toLong();
      return result < 0 ? Long.MAX_VALUE : result;
    }

    final Bytes trimmed = uint.trimLeadingZeros();
    if (trimmed.size() <= 8) {
      final long result = trimmed.toLong();
      return result < 0 ? Long.MAX_VALUE : result;
    } else {
      // clamp to the largest int.
      return Long.MAX_VALUE;
    }
  }

This is in besu/evm/internal/Words.java.

[DavePearce]

So, the sequence is:

1. Random big integer created in MxpTest here:

      size1 = EWord.of(util.getRandomBigIntegerByBytesSize(0, MAX_BYTE_SIZE));
      offset1 = EWord.of(util.getRandomBigIntegerByBytesSize(0, MAX_BYTE_SIZE));

2. This is passed in as one of the arguments for a REVERT or RETURN, after being clamped to Long.MAX_VALUE (as above).
3. MemorySpan is created to represent the RETURN_DATA which is very large, and this then fails assigning the field RETURN_DATA_OFFSET in the relevant Trace.java (because this field is marked as an i32).

@letypequividelespoubelles How would you want to proceed from here? Seems like we could use clampedToInt() in this case. Or perhaps its better to restrict the values for size1 and/or offset1 above? Otherwise it seems a bit iffy to me.

[DavePearce]

@letypequividelespoubelles I think we can close this now right?

[letypequividelespoubelles]

yes I think @OlivierBBB 's #1545 fixed it