| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Various tests set DEBUGINFOD_TIMEOUT to 10. Which is less than the default
of 90. None of the tests relied on a lower timeout. So just don't set it.
Signed-off-by: Mark Wielaard <[email protected]>
|
| |
|
|
|
|
|
|
| |
At startup the debuginfod server does a scan and groom cycle. Make
sure to wait for that before triggering a new one with SIGUSR1 or
SIGURST2.
Signed-off-by: Mark Wielaard <[email protected]>
|
| |
|
|
|
|
|
|
| |
Always set DEBUGINFOD_CACHE_PATH to an unique (new) directory
and make sure that each debuginfod invocation uses a new sqlite
database.
Signed-off-by: Mark Wielaard <[email protected]>
|
|
|
tests/run-debuginfod-find.sh was a massive test script with many broadly
varying tests. This caused the test script to fail when any number of
things went wrong and because of its intertwined nature, detecting the
source of a failure could be difficult. The size of the test script
also meant many unrelated tests were run making the testing process
unnecessarily lengthy.
This patch fractures tests/run-debuginfod-find.sh into smaller, more
manageable individual test script files. This ensures that when failure
occurs, a programmer can easily determine where their patch went
wrong. It also allows programmers to specify exactly which tests to
run, making testing more efficient. Redundancies are also reduced by
placing code in tests/debuginfod-subr.sh.
Signed-off-by: Noah Sanci <[email protected]>
|
