[Libguestfs] virt-v2v valgrind errors in libosinfo

[Pino Toscano]

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) but it is never
> released.

Oh this is interesting. I read in the documentation that custom blocks
have tag Custom_tag, which is higher than No_scan_tag, and thus they
aren't scanned by the GC. Indeed, even trying to Gc.finalize on the
object inside the lazy seems to have no effect.

I guess this is becase db is a top-level variable in Libosinfo_utils;
is there a way to change that behaviour somehow?

> > > 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 alive even when the osinfo_db gets
> > "out of scope". Considering that the osinfo_db is kept basically
> > statically this should be fine.
> 
> Right.
> 
> I don't believe the current code is wrong, my concern is more about
> clearing up valgrind errors before the release.

Yup, it makes sense to do that.

-- 
Pino Toscano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20200414/ab36c505/attachment.sig>