Bug#695866: Bug#695839: lintian: Long-running instances reserves 2.5+ GBs, but avg RES is < 1G MB
Control: found -1 2.5.9
Control: tags -1 pending
On 2013-02-16 11:34, Niels Thykier wrote:
> [...]
>
> It seems that (part of) this leak can be triggered with something like:
>
> $LAB->visit_packages (sub {
> my ($entry) = @_;
> while (1) {
> eval { $entry->info->index (''); };
> $entry->clear_cache;
> }
> });
>
> So, somewhere in the load of our index do we or perl leak something.
>
> ~Niels
>
>
... and located - it is a ref cycle in indices (e.g. index and
control_index). I believe the leak was introduced in [1] and occurs
because the %children entry for the root happens to include the root
itself. When all entries are then converted into L::Path instances, the
root instance now has a reference to itself via its "children" member.
To be honest, I have not quite figured out how the actual cycle is
created[2]. However, a simple if-guard to prevent the name of the root
entry to appear its own %children entry causes the cycle to disappear
according to Devel::Cycle (and the memory usage from the above code
appears to be stable).
On the downside, this leak was introduced in 2.5.9 and therefore affects
both sid and testing. Fortunately, backporting this should be trivial.
~Niels
[1] ff44271bcd86131c3fd1c195302dd48366f576d2
[2] My reading of the code is that the root entry will have a
hetrogenious children list consisting of its actual children (as L::Path
instances) and the empty string (the "self-ref"). But the latter being
a string should not trigger a cycle.
Reply to: