Sometimes the debuginfod selftest fails due to a timeout, because it
spends too long scanning a huge deploy directory that due to what tests
were ran previously can contain 30K packages.
The test only needs a subset of the feed, so use the new localpkgfeed
class to construct a minimal feed before running the test.
[ YOCTO #14937 ]
(From OE-Core rev: 0795169be206f1d4d140fe378e2476a44d0ce02b)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 855376f518b28248ccd82ef5b2e89e6a8c970542)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This test was occasionally failing for no obvious reason, so refactor
and improve:
- While waiting for the daemon, check that it is still running and
explicitly timeout after 10s when making the HTTP call.
- While waiting for the daemon to be ready, log the current state of the
daemon so we can tell if we're timing out as it is still scanning.
- This was in fact the cause of the intermittant failures, because the
TMPDIR is reused between tests and may contain a large number of
packages. Do the tests in an isolated TMPDIR to hopefully mitigate this
issue and increase the timeout to two minutes.
- Decorate the test using runqemu as such so that can be skipped in
environments without runqemu
- Add a second test that doesn't use runqemu or images, which is faster
but less realistic.
(From OE-Core rev: 88b660aaae2527736b6eccec4c952eee969e20a2)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Primarily, before running the debuginfod-find tool, check that the
debuginfod server has finished sweeping the deploy directory. If we
make the request too soon then there's a rare chance that we run the
client before it has scanned the right packages, and the log gets
swamped with warnings from sqlite due to a race.
Also:
- unset DEBUGINFOD_URLS so the debuginfod doesn't proxy to an upstream
server provided by the host distro
- Lower concurrency to reduce system load and handle systems with lower
maximum open file counts but lots of cores (as the concurrency means
cores*2*2 open files)
- Set the refresh times to 0 so we never rescan during the test
- Only scan the packages for the format which the image is using
- Log the commands that are being invoked
(From OE-Core rev: d65729748253eaa640333198ca8aec05946cb9e8)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
debuginfod writes the files it scans to a database in $HOME, which isn't
ideal when the build trees that get scanned typically are deleted after
the test has finished. This can result in debuginfod trying to return
objects that no longer exist on disk:
libc error: stat /home/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-1032306/tmp/deploy/rpm/core2_64/elfutils-dbg-0.187-r0.core2_64.rpm: No such file or directory
libc error: stat /home/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-1113320/tmp/deploy/rpm/core2_64/elfutils-dbg-0.187-r0.core2_64.rpm: No such file or directory
libc error: stat /home/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-1113320/tmp/deploy/rpm/core2_64/elfutils-dbg-0.187-r0.core2_64.rpm: No such file or directory
Solve this, and save writing a database on disk at all, by using the
special database path :memory: which keeps the database in memory only,
so state can't leak between tests.
(From OE-Core rev: d1c2aa3d241bd17d68e8e38d9399cbb0a3f3b912)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a new selftest to exercise the debuginfod support, by starting a
debuginfod on DEPLOY_DIR and verifying that an image can fetch the
symbols for a binary.
(From OE-Core rev: d035fd394fd2747ab4b75867af6123f3efb1990f)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
