If there was no quoting character, the options could run off the end
of the string and into whatever string which happened to be following
in memory.
This bug was revealed when libguestfs was compiled on arm.
For some reason the fs->device field was not set for swap devices.
Apparently this did not matter before (this bug has existed since at
least libguestfs 1.16), but in commit 6ee80b8dac we started to depend
on the fs->device field being non-NULL. This resulted in segfaults
when inspecting any guest which had a swap device, eg:
#0 __strcmp_sse42 () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:164
#1 0x00007ffff7d740cb in parent_device_already_probed (g=0x703a70,
partition=0x6f79b0 "/dev/vda4") at inspect.c:156
#2 0x00007ffff7d73e00 in guestfs__inspect_os (g=0x703a70) at inspect.c:83
#3 0x00007ffff7cee11d in guestfs_inspect_os (g=0x703a70) at actions-1.c:397
This commit sets fs->device to the device name.
(Thanks Matthew Booth for first noticing this problem.)
Rename guestfs_safe_malloc et al to guestfs___safe_malloc etc.
To use the private functions, code now has to define
-DGUESTFS_PRIVATE_FUNCTIONS=1. This will make it easier for us in
future to work out which programs are using these functions and to
minimize both the number of programs and the functions they are
calling.
Note that the Perl, Python, OCaml, Ruby and Java bindings use
guestfs_safe_* calls. None of the other bindings do. This is a bug
(in the bindings using those functions): these functions will call the
out of memory callback on failure. This function defaults to abort(),
and since this happens from a language binding, there is no way to
change this default.
Commit ed7fda161e changed the g->drives
linked list into an array, and also made a subtle change to the
(undocumented) semantics of drives in the rare case when qemu is
relaunched.
Every time we go back to the CONFIG state, we should free the drives
array. However there was one place where this was not happening.
This was caught by the tests of the protocol, but only when using the
default (appliance) method, not the libvirt method which we were more
interested in testing in Fedora.
When testing on Debian using the appliance method, we therefore hit
this bug for the first time.
This relates to or fixes the following commits:
commit 9df159b34a
commit 33f49d85c2
commit ed7fda161e
In the previous code, appliance was unconditionally set to NULL and so
we never added the dummy appliance slot to g->drives. This probably
doesn't matter, since hotplugging doesn't work for the 'appliance'
attach-method. Despite that, it's better to get this right.
This fixes commit ed7fda161e.
These configure flags enable code profiling (with gprof) and code
coverage (with gcov) respectively.
Although this is a nice idea, it's not currently very useful.
Libtool mangles filenames in such a way that gcov cannot locate its
datafiles.
Profiling is of dubious utility with libguestfs which is not CPU-bound
and relies extensively on running external programs (oprofile-like
system profiling that took into account libguestfs + qemu or
libguestfs + qemu + the appliance + filesystem tools *would* be
useful).
Also neither flag will help in capturing data from the appliance.
See the comment from the code:
NB about Windows 8: No location we've found so far contains a
suitable icon for Win8. In particular, explorer.exe definitely
does *not* contain any Windows logo as a resource (I checked).
Therefore the "basket icon" that this produces is just a stand-in
until we have a better idea for solving this problem.
and:
https://bugzilla.redhat.com/show_bug.cgi?id=801117
