It seems as if this is just a variation on the previous libvirt
suppression.
==2042391== 61 (48 direct, 13 indirect) bytes in 1 blocks are definitely lost in
loss record 267 of 507
==2042391== at 0x4846464: calloc (vg_replace_malloc.c:1340)
==2042391== by 0x54EE318: g_malloc0 (gmem.c:163)
==2042391== by 0x5017D4C: virClassNew (virobject.c:189)
==2042391== by 0x523CCB9: virDataTypesOnce.lto_priv.0 (datatypes.c:111)
==2042391== by 0x4D8BE42: __pthread_once_slow (pthread_once.c:116)
==2042391== by 0x50345E1: virOnce (virthread.c:44)
==2042391== by 0x523CD6A: virGetConnect (datatypes.c:121)
==2042391== by 0x51FBC1F: virConnectOpenInternal (libvirt.c:893)
==2042391== by 0x51FCC11: virConnectOpenAuth (libvirt.c:1271)
==2042391== by 0x4A3ECAD: guestfs_int_open_libvirt_connection.constprop.0 (li
bvirt-auth.c:224)
==2042391== by 0x4A1D62A: launch_libvirt.lto_priv.0 (launch-libvirt.c:389)
==2042391== by 0x4993739: guestfs_launch (launch.c:114)
(cherry picked from guestfs-tools commit 8790af0266a808c8a04927bb5039be06cbc3da54)
(cherry picked from commit 4ed83ffdbe)
OCaml PCRE.compile doesn't free up regexps if they are stored in
globals. However the valgrind suppression for this matched the old
function name, not the new PCRE2 name. Valgrind errors looked like:
==1799651== 145 bytes in 1 blocks are possibly lost in loss record 2,927 of 4,168
==1799651== at 0x484186F: malloc (vg_replace_malloc.c:381)
==1799651== by 0x4D5F2E5: pcre2_compile_8 (pcre2_compile.c:10250)
==1799651== by 0x29E077: guestfs_int_pcre_compile (pcre-c.c:196)
==1799651== by 0x2B725F: camlOVA__entry (OVA.ml:392)
==1799651== by 0x2859A8: caml_program (in /home/rjones/d/virt-v2v/v2v/virt-v2v)
==1799651== by 0x40F9D8: caml_start_program (in /home/rjones/d/virt-v2v/v2v/virt-v2v)
==1799651== by 0x40FD86: caml_startup_common (in /home/rjones/d/virt-v2v/v2v/virt-v2v)
==1799651== by 0x40FDDC: caml_startup (in /home/rjones/d/virt-v2v/v2v/virt-v2v)
==1799651== by 0x28523F: main (in /home/rjones/d/virt-v2v/v2v/virt-v2v)
(cherry picked from virt-v2v commit 2949109ff9f7a081b1a4b475b9f7bcbef5b45ee0)
(cherry picked from commit ede3632612)
OCaml 4.08 introduces a stdlib Option module which looks a bit like
ours but has a number of differences. In particular our functions
Option.may and Option.default have no corresponding functions in
stdlib, although there are close enough equivalents.
This change was automated using this command:
$ perl -pi.bak \
-e 's/Option.may/Option.iter/g; s/Option.default /Option.value ~default:/g' \
`git ls-files`
Update common module to include:
commit cffa077323fafcdfcf78e230c022afa891a6b3ff
Author: Richard W.M. Jones <rjones@redhat.com>
Date: Mon Feb 20 12:11:51 2023 +0000
mlstdutils: Rework the Option module to be compatible with stdlib
(cherry picked from commit 250ee85839)
This reverts one part of commit 85235aec83 related to reference
counts. Py_BuildValue always increments the reference count (when it
succeeds) and I could not reproduce the Python 3 problem that was
described there.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
(cherry picked from commit e07304de86)
The presence of this file complicates ./configure and you also have to
remember to update it on each release. Replace it with a simple
RELEASE_DATE set in ./configure when the version is updated.
I also had to make a minor change to the generator which was using
this file both to check it was run from the source directory and to
get an exclusive lock. We now use podwrapper.pl.in for this.
(cherry picked from commit f68752462e)
It fails when run twice with:
../run cargo clean
error: could not find `Cargo.toml` in `/home/rjones/d/libguestfs/rust` or any parent directory
As this is an optional step don't fail here.
(cherry picked from commit c7d54697ca)
We require libvirt >= 0.10.2, and we included code to check this at
configure-, compile- and run-time. Remove the checks at compile and
run time (keep the ./configure check). Libvirt 0.10.2 was released
over 10 years ago so it's safe to assume that everyone has it by now.
(cherry picked from commit b9ccfe3e03)
The event callback gets a buffer parameter which is usually something
like a log message. However as it comes from C it is not necessarily
well-formed (eg) UTF-8 but could contain any old sequence of bytes.
In the test case provided by the reporter, we failed to encode the
buffer as 'str' with this error:
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc3 in position 137: unexpected end of data
Use 'bytes' instead. Strictly speaking this changes the type
signature of the callbacks, but our existing Python tests which just
print the buffer using '%s' don't fail and in any case we don't
guarantee the stability of non-C APIs.
Reported-by: Yonatan Shtarkman
See: https://listman.redhat.com/archives/libguestfs/2023-February/030653.html
(cherry picked from commit bbf396fc55)
In the case that building the parameters to the Python event callback
fails, args was returned as NULL. We immediately tried to call
Py_INCREF on this which crashed. Returning NULL means the Python
function threw an exception, so print the exception and return (there
is no way to return an error here - the event is lost).
Reported-by: Yonatan Shtarkman
See: https://listman.redhat.com/archives/libguestfs/2023-February/030653.html
(cherry picked from commit 6ef5837e2d)
Run this command across the source:
perl -pi.bak -e 's/(20[012][0-9])-20[12][012]/$1-2023/g' `git ls-files`
and remove changes to po{,-docs}/*.po{,t} (these will be regenerated
later when we run 'make dist').
Update common module to 3253cd99d135d5eb788a0477459b43a269e8cca6
No significant changes that affect virt-v2v now, but it adds some
extra functions to Std_utils that might be used one day.
Cherry picked from virt-v2v commit c7c9dac4f84580190b0e4f7c2e68970192f4bad3
It might be left over from a previous failed run. Best to unlink the
old file before starting qemu-nbd, so there's no possibility of
getting confused later when we wait for the file to appear.
This test fails for reasons I have not fully understood yet. However
one thing I noticed is that the Unix domain socket and PID file used
the tests are placed in the tests/ directory, not the tests/nbd/
subdirectory, so let's fix that:
Starting qemu-nbd fedora-nbd.img -t --pid-file /home/rjones/d/libguestfs-rhel-9.2/tests/nbd.pid --format raw -p 63668 ...
Starting qemu-nbd fedora-nbd.img -t --pid-file /home/rjones/d/libguestfs-rhel-9.2/tests/nbd.pid --format raw -p 60684 ...
Starting qemu-nbd fedora-nbd.img -t --pid-file /home/rjones/d/libguestfs-rhel-9.2/tests/nbd.pid --format raw -k /home/rjones/d/libguestfs-rhel-9.2/tests/unix.sock ...
Fixes: commit 6d32773e81
Add an API to return the build ID of the guest. This to allow a
future change to be able to distinguish between Windows 10 and Windows 11
which can only be done using the build ID.
For Windows we can read the CurrentBuildNumber key from the registry.
For Linux there happens to be a BUILD_ID field in /etc/os-release.
I've never seen a Linux distro that actually uses this.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
