MemoryError exception in multi_unit_abbrev_noprint.wasm test on x86 32-bit

[rathann]

When running the testsuite of version 111 with #5317 and #5349 applied on x86 32-bit under Fedora rawhide, I get the following MemoryError exception:

$ ./check.py --binaryen-bin /builddir/build/BUILDROOT/binaryen-111-1.fc38.i386/usr/bin --binaryen-lib /builddir/build/BUILDROOT/binaryen-111-1.fc38.i386/usr/lib/binaryen
warning: no passes specified, not doing any work
warning: no passes specified, not doing any work
warning: no passes specified, not doing any work
warning: no passes specified, not doing any work
warning: no output file specified, not emitting output
warning: no output file specified, not emitting output
warning: no output file specified, not emitting output
warning: no output file specified, not emitting output
warning: no output file specified, not emitting output
warning: no output file specified, not emitting output
warning: no output file specified, not emitting output
warning: no output file specified, not emitting output
warning: no output file specified, not emitting output
warning: no output file specified, not emitting output
warning: no output file specified, not emitting output
warning: no output file specified, not emitting output
warning: no output file specified, not emitting output
warning: no output file specified, not emitting output
warning: no output file specified, not emitting output
[ checking --version ... ]
Parsed CHANGELOG.md version: 111
.. /builddir/build/BUILDROOT/binaryen-111-1.fc38.i386/usr/bin/wasm-as --version
.. /builddir/build/BUILDROOT/binaryen-111-1.fc38.i386/usr/bin/wasm-ctor-eval --version
.. /builddir/build/BUILDROOT/binaryen-111-1.fc38.i386/usr/bin/wasm-dis --version
.. /builddir/build/BUILDROOT/binaryen-111-1.fc38.i386/usr/bin/wasm-emscripten-finalize --version
.. /builddir/build/BUILDROOT/binaryen-111-1.fc38.i386/usr/bin/wasm-fuzz-types --version
.. /builddir/build/BUILDROOT/binaryen-111-1.fc38.i386/usr/bin/wasm-metadce --version
.. /builddir/build/BUILDROOT/binaryen-111-1.fc38.i386/usr/bin/wasm-opt --version
.. /builddir/build/BUILDROOT/binaryen-111-1.fc38.i386/usr/bin/wasm-reduce --version
.. /builddir/build/BUILDROOT/binaryen-111-1.fc38.i386/usr/bin/wasm-shell --version
.. /builddir/build/BUILDROOT/binaryen-111-1.fc38.i386/usr/bin/wasm-split --version
.. /builddir/build/BUILDROOT/binaryen-111-1.fc38.i386/usr/bin/wasm2js --version
...
.. multi_unit_abbrev_noprint.wasm
executing:  warning: no output file specified, not emitting output
/builddir/build/BUILDROOT/binaryen-111-1.fc38.i386/usr/bin/wasm-opt -g --roundtrip --roundtrip --roundtrip split.wast
executing:  /builddir/build/BUILDROOT/binaryen-111-1.fc38.i386/usr/bin/wasm-opt -g --roundtrip --roundtrip --roundtrip split.wast --debug
Traceback (most recent call last):
  File "/builddir/build/BUILD/binaryen-version_111/./check.py", line 416, in <module>
    sys.exit(main())
             ^^^^^^
  File "/builddir/build/BUILD/binaryen-version_111/./check.py", line 399, in main
    TEST_SUITES[test]()
  File "/builddir/build/BUILD/binaryen-version_111/scripts/test/wasm_opt.py", line 72, in test_wasm_opt
    debugged = support.run_command(cmd + ['--debug'], stderr=subprocess.PIPE)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/builddir/build/BUILD/binaryen-version_111/scripts/test/support.py", line 179, in run_command
    out, err = proc.communicate()
               ^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/subprocess.py", line 1207, in communicate
    stdout, stderr = self._communicate(input, endtime, timeout)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/subprocess.py", line 2079, in _communicate
    data = os.read(key.fd, 32768)
           ^^^^^^^^^^^^^^^^^^^^^^
MemoryError
$ 

[rathann]

It looks like this is the only failing test. After disabling it, the rest of the testsuite succeeds on x86 32-bit.

[tlively]

@kripken, it looks like we just checked in some binary and round trip it a few times to make sure we don't crash? That seems like an extremely low-value test, since there's no way to even tell what kind of problem it is guarding against. Can we just delete it?

[rathann]

Interestingly, I can't reproduce this failure on ARM 32-bit (well, qemu-user-static-arm running on ARM 64-bit), same OS.