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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
