Hi Adam,
> Ah, indeed, the failure mode means that the log never made it to
> buildd.d.o.
Curious, not heard of that failure mode — is there someplace I can
learn about that? No worries if not.
> I've attached a copy of the log from zani.
Ah, thanks. Unfortunately, it does not point us straight to the
solution. I note that you titled this bug "package OOMs" — I point
this out because the "OOM" text the log is actually the name of the
test. As in, here is tests/integration/corrupt-dump.tcl:
447 test {corrupt payload: OOM in rdbGenericLoadStringObject} {
448 start_server [list overrides [list loglevel verbose use-exit-on-panic
yes crash-memcheck-enabled no] ] {
449 r config set sanitize-dump-payload no
450 catch { r RESTORE x 0 "\x0A\x81\x7F\xFF\xFF\xFF\xFF\xFF\xFF\xFF […]
451 assert_match "*Bad data format*" $err
452 r ping
453 }
454 }
Do we have confirmation somewhere that the build is actually OOMing,
rather than it just timing out on a test that was designed to test
*for* an OOM condition. This OOM-related bug *should* be fixed by
virtue of them adding the test to begin with (!) but if we can show
that it is still OOMing, I suspect that upstream will be able to
address it quickly.
If it helps, this test was added in this commit:
https://github.com/antirez/redis/commit/7ca00d694d44be13a3ff9ff1c96b49222ac9463b
... which was in:
$ git tag --contains 7ca00d694d44be13a3ff9ff1c96b49222ac9463b
6.2-rc1
6.2-rc2
6.2-rc3
Not sure if previous s390x builds were failing, which might be another
route to fixing this.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org 🍥 chris-lamb.co.uk
`-
