Hi Reinhard, On 03-10-2021 16:21, Reinhard Tartler wrote: > Note that the test doesn't do xz, but zstd compression, > cf. https://github.com/klauspost/compress/blob/master/zstd/README.md > <https://github.com/klauspost/compress/blob/master/zstd/README.md> > so your comment regarding --threads=0 does not seem to apply? -- not > sure, please let me know what you think. I was just using $(xz --threads=0) as an example, not claiming that that was what's happening. Just that large amounts of cores and/or memory can trigger weird "bugs". > The consistent OOM is surprising given that you state that the worker > has 250GB of RAM. Looking at the logs, > I note that the tests are being passed the option -p 160 by the > dh-golang helper, so it will build > and run test executables concurrently. That confirms to me that we are > indeed running on these 250GB/160 core workers. We only have one armhf host, so *all* armhf tests are run there. I'm also not seeing this problem back in the logs: https://ci.debian.net/munin/ci-worker-armel-01/ci-worker-armel-01/memory.html. But maybe the incident is too short to be caught by the once per 5 minutes poll. > Is it possible that armhf is setting up ulimits that limits the amount > of memory the test may allocate? root@ci-worker-armel-01:~# ulimit unlimited > As far as I understand, all golang packages use autodep8 to declare the > tests, > which doesn't support adding the Architecture field. I think you're right, but maybe we should fix autodep8 to enable the change like the other overwrites in section `PACKAGE-SPECIFIC CONFIGURATION` of $(man autodep8). > In order to get > around this, > I guess I could remove the Testsuite field from debian/control and add a > debian/tests/control that looks similar to what autodep8 generates, but adds > the Architecture: !armhf restriction. Maybe until autodep8 is fixed? I fear that this may cause future trouble if/when autodep8 support for golang gets updated. Paul
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature