mass testing scripts

Roland McGrath roland at redhat.com
Mon Jan 5 07:27:31 UTC 2009


I've refined the stuff I posted before and cobbled together some basic
scripts for doing mass testing on .debug files from the distros.

I've put the scripts at:

git://git.fedorapeople.org/~roland/debuginfo-test-scripts.git
http://fedorapeople.org/gitweb?p=roland/public_git/debuginfo-test-scripts.git

and here's the README from there:

These are some scripts for unpacking lots of -debuginfo rpms and then
running tests against all the ELF files therein.

Please send all questions to <elfutils-devel at lists.fedorahosted.org>.


Start with a mostly empty directory where you have a ton of free disk
space.  I just use the checkout itself, but you can also cd into a
different directory to hold the data and call the scripts by names
not starting with ./ like I show here.

$ git clone git://git.fedorapeople.org/~roland/debuginfo-test-scripts.git test
$ cd test

Now extract a giant mound of data:

$ ./extract-distro.sh /mirror/fedora/development

The arguments are directories where it will find "*/debug" subdirectories
containing many .rpm files.  The example is a mirror of rawhide; other
examples that work are .../releases/10/Everything and .../updates{,/testing}.

This will chug and chug for some hours, depending how much is in the
directories you gave it.  It fills the current directory with one
subdirectory for each rpm it unpacked, with names from the rpm file names,
e.g. foo-debuginfo-1.0-1.i386/.

You can run this again later with more directories or the same ones.
It will silently skip any rpm files it has already unpacked.

For all of rawhide (four arch's) this was around 35G when done, I think.
It chugs in parallel doing unpacking and compressing, with each new
subdirectory grows and then shrinks substantially.  So be sure you have
plenty of breathing room on the disk.

This is probably overly parallel and chugs along swamping the machine.
Run it on a spare (fastish) machine you are not using, or while you sleep.


Once unpacked and repacked, each rpm subdir contains:

	src.tar.bz2		of all usr/src/debug files
	usr/lib/debug/*.bz2	compressed in place
	summary			one line, counts
	exec			list of file names of each type
	dyn
	rel
	archive

The summary file looks like:

src 40M->5.6M exec 18 dyn 272 rel 3 archive 17 bz2 60M->39M

That says 40M of usr/src/debug files (du -sh when unpacked) turned into
5.6M of src.tar.bz2 on disk; the rpm had 18 ET_EXEC files, 272 ET_DYN
files, 3 ET_REL files, 17 .a files; compressing each of those ELF files
took 60M of usr/lib/debug space down to 39M.

The summary file is for edification mainly, but machine parseable too.  A
summary will include "src missing", "debug missing", and/or a "bogon" count
if something unusual happened during unpacking.  You should look into any
of those.

The lists of files are used by the other scripts:

$ ./list-files.sh exec [rpm...]

or dyn/rel/archive or "norel" or "all" will spit the names of all the
appropriate files in the given rpms, or in the whole set if no rpm... args.


Now, to actually do some testing!  So far we have:

$ ./single-file-test.sh [all|norel|etc] workdir testcmd ...

This runs the "testcmd ..." in isolation, once for each ELF file of the
given type(s).  Each {} in the "testcmd ..." line is replaced with an
individual file name when it's run.  Each test runs inside a subdirectory
created in workdir (can be any path, gets created as needed).

When a test run completes normally, its subdirectory is removed.
At the end of the run, the only things left in workdir/ will be
the subdirectories for cases that failed.

The testcmd is considered a success only if it exits with 0 status, sends
no output to its stdout or stderr, and leaves no files behind in its
current directory.  Also note that the command arguments do not preserve
proper quoting.  So if you need to get fancy just write a wrapper script
that needs only the file name argument.

The script's exit status is 0 for an orderly run regardless of test
failures.  It only fails for some problem setting up the test runs, and
only such errors should show up on stderr.  For each failure, the script
writes one line to stdout:

	FAIL (status) foo-debuginfo-1.2-3.ppc/.../name dirname

Where (status) is (1) or (0) or whatever the exit status was, or is (files)
when it was 0 but extra files were left behind.  A line with (0) means
there was something sent to stdout/stderr, which shows up in dirname/log.
The rpm/file name shows the file that broke the test.  workdir/dirname/
contains whatever it left behind (e.g. core dumps), plus:

	cmd		exact command we ran
	log		stdout/stderr content
	status		0/1/etc
	name		uncompressed ELF file (from foo-debuginfo.../name.bz2)

Concrete examples:

$ ./single-file-test.sh all elflint-test eu-elflint -d -q --gnu-ld {}
$ ./single-file-test.sh all elfcmp-test eu-elfcmp -q {} {}

---

Enjoy!

Please send all questions to <elfutils-devel at lists.fedorahosted.org>.


More information about the elfutils-devel mailing list