Hi, On 2022-09-22 11:19, Paul Gevers wrote: > Source: glibc > Version: 2.33-7 > Severity: serious > User: debian-ci@lists.debian.org > Usertags: flaky > > Dear maintainer(s), > > I looked at the results of the autopkgtest of your package. I noticed that > it regularly fails on armel while testing if other packages can migrate. A > retry (or retry of retry) passes, so it doesn't seem related to those > packages. > > Because the unstable-to-testing migration software now blocks on > regressions in testing, flaky tests, i.e. tests that flip between > passing and failing without changes to the list of installed packages, > are causing people unrelated to your package to spend time on these > tests. I now looked at it because both gcc-11 and gcc-12 showed up as > regressing the glibc autopkgtest. > > Don't hesitate to reach out if you need help and some more information > from our infrastructure. Please find my answer (and questions for each test below). > https://ci.debian.net/packages/g/glibc/testing/armel/ > > https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/23501044/log.gz > > ---------- > FAIL: elf/tst-debug1 > original exit status 1 > Didn't expect signal from child: got `Bus error' > ---------- I have not been able to reproducible this bug after 1M tests on amdahl.d.o, an RPI3 (running an arm64 kernel) and a STM32MP1 board (armhf). Would it be possible to give more details, like any corresponding dmesg entry to have a better idea of the issue? > https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/26322757/log.gz > > nptl/tst-rwlock9 > [...] > Timed out: killed the child process > Termination time: 2022-09-22T07:41:04.502168635 > Last write to standard output: 2022-09-22T07:28:34.991525943 I have been able to reproduce that one, with a probability of around 1/2500 on average. I have tracked it down to this bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24774 It appears to be fixed by this patch that didn't seem to attract a lot of interest: https://sourceware.org/pipermail/libc-alpha/2021-September/131546.html I just reviewed and tested it, so let's see if it get merged soon: https://sourceware.org/pipermail/libc-alpha/2021-September/131546.html > https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/26218800/log.gz > https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/26223226/log.gz > https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/26322746/log.gz > > ---------- > FAIL: rt/tst-cpuclock2-time64 > original exit status 1 > live thread clock ffb6e90e resolution 0.000000001 > live thread before sleep => 0.000254800 > self thread before sleep => 0.000728320 > live thread after sleep => 0.473986200 > self thread after sleep => 0.001080840 > clock_nanosleep on process slept 97739240 (outside reasonable range) > ---------- I also can't reproduce this one after 100000 tests on amdahl.d.o, an RPI3 (running an arm64 kernel) and a STM32MP1 board (armhf). According to upstream it seems that this test is known to fail heavy loaded hosts as it relies on wall time. Is it the case of the debci workers, do they have dedicated CPUs to run their tests? Are the armel workers different than the others? Nevertheless the part of the test that relies on wall time has been removed from upstream so this should be considered as fixed in glibc 2.35 that is now in testing: https://sourceware.org/git/?p=glibc.git;a=commit;h=f3c6c190388bb445568cfbf190a0942fc3c28553 > https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/25779292/log.gz > > /bin/bash testdata/gen-XT5.sh > /tmp/autopkgtest-lxc.pjd0aipn/downtmp/build.Ui1/src/build-tree/armel-libc/timezone/testdata/XT5.tmp > /bin/bash: line 1: /tmp/autopkgtest-lxc.pjd0aipn/downtmp/build.Ui1/src/build-tree/armel-libc/timezone/testdata/XT5.tmp: > No such file or directory This has been fixed in glibc 2.35 that is now in testing: https://sourceware.org/git/?p=glibc.git;a=commit;h=62db87ab24f9ca483f97f5e52ea92445f6a63c6f Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net
Attachment:
signature.asc
Description: PGP signature