Hi Sean, On 09-08-2022 05:08, Sean Whitton wrote:
It looks like Lisp just ran out of memory.
Yes, but it does so systematically.
Indeed, I can't see this failure on debci.debian.org at present,
Huh? Did you check https://ci.debian.net/packages/c/cl-ironclad/testing/armhf/ or https://ci.debian.net/packages/c/cl-ironclad/testing/armel/ You'll see there that cl-ironclad was retried with sbcl about 11 + 10 times and every time it failed (and never succeeded).
which makes sense if it's a random OOM problem on weaker architectures like armhf -- so, not the fault of the new sbcl upload.
This isn't random. And, our armhf box has 255 GB of RAM (and armel VM has 26 GB), so running out of memory isn't likely. What can happen is that threads use too much resources for the address space, but that's something under control of the packages in question if I'm correct (but please correct me if I misunderstand). I'm not saying it's (easily) fixable, just that it systematically runs out of reachable memory during the particular test.
Is it possible to label the tests as flaky on only a single architecture?
Yes [1], but I'm not seeing flaky behavior. Paul[1] add the skippable restriction to the test you want to be able to ignore and exit with exit code 77 when the failure happens on the architecture you want to ignore. If you want to skip the test on armhf and armel altogether, I rather suggest you use an "Architecture: !armel !armhf" line in the d/t/control section of the test.
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature