Wherever we had code which did:
if (something_bad) {
perror (...);
exit (EXIT_FAILURE);
}
replace this with use of the error(3) function:
if (something_bad)
error (EXIT_FAILURE, errno, ...);
The error(3) function is supplied by glibc, or by gnulib on platforms
which don't have it, and is much more flexible than perror(3). Since
we already use error(3), there seems to be no downside to mandating it
everywhere.
Note there is one nasty catch with error(3): error (EXIT_SUCCESS, ...)
does *not* exit! This is also the reason why error(3) cannot be
marked as __attribute__((noreturn)).
Because the examples can't use gnulib, I did not change them.
To search for multiline patterns of the above form, pcregrep -M turns
out to be very useful:
pcregrep --buffer-size 10M -M '\bperror\b.*\n.*\bexit\b' `git ls-files`
Calling _exit(2) in the child process has the side effect that
tmp/libguestfsXXXXXX is not cleaned up. Clean it up by ensuring the
handle is properly closed before _exit.
This test has been broken for a while. It is meant to test that when
the appliance cachedir is empty, two simultaneous runs of libguestfs
(both rebuilding the full appliance) will not cause conflicts, because
(eg) the locking in either supermin or libguestfs is not working.
However the test only set $TMPDIR, but the ./run script sets
$LIBGUESTFS_CACHEDIR which overrides $TMPDIR, so it was simply reusing
the existing appliance, and hence not testing anything.
Fix this by clearing $LIBGUESTFS_CACHEDIR.
Note the test now takes a lot longer to run since it does a full
appliance rebuild.
Instead of hardcoding the location of perl (assuming it is installed in
/usr), use /usr/bin/env to run it, and thus picking it from $PATH.
This makes it possible to run these scripts also on installations with
perl in a different prefix than /usr.
Also, given that we want enable warnings on scripts, turn the -w
previously in shebang to explicit "use warnings;" in scripts which
didn't have it before.
All tests run under the ./run binary. For a long time the ./run
binary has set the $PATH environment variable to contain all of the
directories with binaries in them.
Therefore there is no reason to use ../fish/guestfish instead of just
plain guestfish (and the same applies to other built binaries).
This test worked by uploading a 100MB file into a 100MB container and
seeing the inevitable crash. Unfortunately virtio-mmio (used on
aarch64) is quite slow. Since this test is not testing the speed of
virtio-mmio, use a smaller test file so the test finishes in a
reasonable time.
This test has not been run since 2012 as it depends on specifics of
how supermin and new-style appliances work (see
commit 2d89aef897).
This commit removes the test entirely.
Review every test(!) to ensure that it:
- Doesn't use a generic name (eg. "test1.img", "test.out") for any
temporary file it needs.
- Does instead use a unique name or a temporary name (eg. a name like
"name-of-the-test.img", or a scratch disk).
- Does not use 'rm -f' to clean up its temporary files (so we can
detect errors if the wrong temporary file is created or removed).
This allows tests to be run in parallel, so they don't stomp on each
other's temporary files.
This large, but mainly mechanical commit, renames "attach method"
everywhere to "backend".
Backwards compatibility of the API (guestfs_{set,get}_attach_method)
and environment (LIBGUESTFS_ATTACH_METHOD) is maintained, but in new
code use guestfs_{set,get}_backend and LIBGUESTFS_BACKEND instead.
The default backend (launching qemu directly) is now called 'direct'
instead of 'appliance', although you can still use 'appliance' as a
synonym.
This file was present in git, but missing from the tarball.
Don't actually run the test: it depends on details of how the
appliance is constructed which would fail for old-style appliances.
Commit ed7fda161e changed the
way that the drives are handled across appliance shutdowns.
Previously during the following sequence of calls:
create the handle
add drive(s)
launch
kill subprocess
launch
the added drives are still in the handle at the second launch.
After the above commit, the added drives are removed from the handle,
which means the second launch happens with no drives (which could be
an error).
This was never actually defined either way, so in this case fix the
test to re-add the drive before the second launch.
Since hotplugging was added, it isn't really feasible to return to the
original semantics, since users might remove drives, in which case we
have lost information about those drives so we cannot restore them on
the second launch.
NOTE: PLEASE CALLERS DON'T DO THIS! Always use a new handle for each
launch of the appliance.
Since our minimum supported version is now 1.16 and mount was fixed in
1.13.16, it is now safe to replace mount-options + empty options with
mount wherever it occurs.
MALLOC_PERTURB_ is a glibc feature which causes malloc to wipe memory
before and after it is used, allowing both use-after-free and
uninitialized reads to be detected with relatively little performance
penalty:
http://udrepper.livejournal.com/11429.html?nojs=1
Modify the ./run script so that it always sets this.
We were already using MALLOC_PERTURB_ in most tests. Since ./run is
now setting this, we can remove it from individual Makefiles. Most
TESTS_ENVIRONMENT will now simply look like this:
TESTS_ENVIRONMENT = $(top_builddir)/run --test
This option, when added via
TESTS_ENVIRONMENT = [...] $(top_builddir)/run --test
allows us to run the tests and only print the full output (including
debugging etc) when the test fails.
