Describe the bug

The corrupt payload: fuzzer findings - OOM in dictExpand test within the integration/corrupt-dump unit results in memory exhaustion on the s390x architecture. The intention of the test is to ensure that it does not OOM (as it does not on most architectures), but it still OOMs on s390x.

To reproduce

% uname -a
Linux zelenka 4.19.0-17-s390x #1 SMP Debian 4.19.194-3 (2021-07-18) s390x GNU/Linux

% ./runtest --clients 1 --verbose --single integration/corrupt-dump --only "corrupt payload: fuzzer findings - OOM in dictExpand"
[...]
[skip]: corrupt payload: fuzzer findings - stream integrity check issue
[skip]: corrupt payload: fuzzer findings - infinite loop
[skip]: corrupt payload: fuzzer findings - hash ziplist too long entry len
[skip]: corrupt payload: OOM in rdbGenericLoadStringObject

[hangs here running the "corrupt payload: fuzzer findings - OOM in dictExpand" test]

Expected behavior

That the test passes, as it does on all other architectures.

Additional information

This test was added as part of an allocation-related overhaul in 7ca00d6. It is unknown whether the changes in this diff introduced the underlying problem (instead of merely introducing a test that exposes it).

This was originally tracked in @Debian here: https://bugs.debian.org/982122

Thanks to Julien Cristau and Adam Barratt for their help nailing down this issue.