search for: osinfodb_t_finalize

On Tue, Apr 14, 2020 at 12:37:07PM +0200, Pino Toscano wrote: > > Unfortunately we never free the database. > > Hm it is never freed? Wouldn't that result in actual leaks, since > OsinfoDb_t_finalize (g_object_unref'ing the OsinfoDb) wouldn't be > called? I was thinking because of this: https://github.com/libguestfs/virt-v2v/blob/cc294b7735dda467179b93a061d3631ac3547f26/v2v/libosinfo_utils.ml#L24 which IIUC will allocate a DB (on first access) but it is never released. (Note: I...

Hi Pino: I've suppressed some OCaml and libosinfo valgrind errors in virt-v2v. The remaining valgrind errors are here: http://oirase.annexia.org/tmp/v2vvg/ They all seem to be basically the same. But I couldn't work out if these are expected leaks in the libosinfo code (in which case we should suppress them), or if they are actual bugs because we are missing a true destructor here:

...er objects (like the devices) inside each OsinfoOs, so it is not possible to get the ownership of all the OsinfoOs (g_object_ref) and then get rid of the OsinfoDb (g_object_unref). > Unfortunately we never free the database. Hm it is never freed? Wouldn't that result in actual leaks, since OsinfoDb_t_finalize (g_object_unref'ing the OsinfoDb) wouldn't be called? > It could be that to express > this properly we'd need to expose (db, os) tuples to the OCaml garbage > collector. I thought about this, and according to knowledge this would be needed only if we want osinfo_os objects al...

On Tuesday, 14 April 2020 15:16:49 CEST Richard W.M. Jones wrote: > On Tue, Apr 14, 2020 at 12:37:07PM +0200, Pino Toscano wrote: > > > Unfortunately we never free the database. > > > > Hm it is never freed? Wouldn't that result in actual leaks, since > > OsinfoDb_t_finalize (g_object_unref'ing the OsinfoDb) wouldn't be > > called? > > I was thinking because of this: > > https://github.com/libguestfs/virt-v2v/blob/cc294b7735dda467179b93a061d3631ac3547f26/v2v/libosinfo_utils.ml#L24 > > which IIUC will allocate a DB (on first access) bu...

This patch series integrates libosinfo in virt-v2v to get the list of files for Windows from libosinfo, if possible. The actual data is still from virtio-win, just unpacked. Pino Toscano (3): build: require libosinfo v2v: add a minimal libosinfo interface v2v: try to get windows driver files from libosinfo m4/guestfs-v2v.m4 | 3 + v2v/Makefile.am | 9 +-

This patch series integrates libosinfo in virt-v2v to get the list of files for Windows from libosinfo, if possible. The actual data is still from virtio-win, just unpacked. Changes from v1: - adapt to use the priority in libosinfo 1.7.0+ - filter out non-pre-installable drivers - collect all the drivers matching the requirements, not just the first, sorting them by priority like libosinfo does