On 11/19/19 9:14 AM, Thomas Lamprecht wrote: > The data passed to this closure was never free'd, depending on the > count of VM/CTs one could get >1 MB of RSS (!) memory leaked per > statd status cycle update run... > > We could also use Scalar::Util's weaken, to weak a copy of this > variable, but as a simple undef works lets do that with a comment.. > > Signed-off-by: Thomas Lamprecht <[email protected]> > --- > > what a bummer... We need to check all (recursive) closures and ensure they are > made undefined after they did their job.. > > PVE/Status/Graphite.pm | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/PVE/Status/Graphite.pm b/PVE/Status/Graphite.pm > index 14180aef..28fa65fd 100644 > --- a/PVE/Status/Graphite.pm > +++ b/PVE/Status/Graphite.pm > @@ -141,6 +141,8 @@ sub assemble { > } > }; > $assemble_graphite_data->($data, $path); > + > + $assemble_graphite_data = undef; # avoid cyclic reference! > } > > PVE::JSONSchema::register_format('graphite-path', > \&pve_verify_graphite_path); >
forgot, already applied.. Thanks to Wolfgang for their moral and counseling support.. _______________________________________________ pve-devel mailing list [email protected] https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
