Skip Menu |
 

This queue is for tickets about the Moose CPAN distribution.

Report information
The Basics
Id: 98807
Status: rejected
Priority: 0/
Queue: Moose

People
Owner: Nobody in particular
Requestors: rmesser [...] intellisurvey.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: possible memory leaks
Date: Thu, 11 Sep 2014 11:37:37 -0700
To: bug-moose [...] rt.cpan.org
From: Robert Messer <rmesser [...] intellisurvey.com>
Download (untitled) / with headers
text/plain 2.6k
I am trying to track down some fairly severe memory leaks our software, and some have been experimenting with various CPAN modules that help locate leaks. As part of that, I tried adding a UNIVERSAL::DESTROY method that checks for cycles in the global destruction phase, under the theory that object that survive to that point are likely leakers. Here is the test script: use strict; use Devel::Cycle; package Foo { use Moose; sub BUILD { my $self = shift; $self->{circle} = $self; } } # Install a universal DESTROY method to check for leaks during the global destruction phase, under # the theory that objects that survive until global destruction are likely candidates for leaking. # NB: this doesn't catch all leaks, apparently because some cycles are broken by perl before we # get here. Maybe? sub UNIVERSAL::DESTROY { my $self = shift; if (${^GLOBAL_PHASE} eq 'DESTRUCT') { find_cycle($self); } } my $f = Foo->new(); This unfortunately didn't report the leak in my own example Foo object, but it does report tons of cycles within Moose code. For example, there are a lot of this form: Cycle (1): $Class::MOP::Instance::A->{'attributes'} => \@B $B->[0] => \%Class::MOP::Attribute::C $Class::MOP::Attribute::C->{'associated_methods'} => \@D $D->[0] => \%Class::MOP::Method::Accessor::E $Class::MOP::Method::Accessor::E->{'attribute'} => \%Class::MOP::Attribute::C and some like this, possibly related to the one above, since both reference attribute and associated_methods: Cycle (1): $Class::MOP::Method::Accessor::BT->{'body'} => \&BU $BU variable $attr => \$BV $$BV => \%Class::MOP::Attribute::BW $Class::MOP::Attribute::BW->{'associated_methods'} => \@BX $BX->[0] => \%Class::MOP::Method::Accessor::BY $Class::MOP::Method::Accessor::BY->{'body'} => \&BZ $BZ variable $class => \$CA $$CA => \%Class::MOP::Class::Immutable::Class::MOP::Class::CB $Class::MOP::Class::Immutable::Class::MOP::Class::CB->{'attributes'} => \%CC $CC->{'auto_deref'} => \%Class::MOP::Attribute::CD $Class::MOP::Attribute::CD->{'associated_methods'} => \@CE $CE->[0] => \%Class::MOP::Method::Accessor::CF $Class::MOP::Method::Accessor::CF->{'body'} => \&CG $CG variable $attr => \$CH $$CH => \%Class::MOP::Attribute::CD If you run the script above you should be able to see the same spew of output (1900+ lines) I'm getting. I'm using Moose 2.1211, Perl 5.20.0. Are these valid leaks? Perhaps the 'attribute' in Class::MOP::Method::Accessor needs to be weakened? Rob
Download (untitled) / with headers
text/plain 215b
Moose stores metaclass objects (which contain many other meta-level objects) in a global that lives as long as the interpreter lives. These objects are only destroyed when the interpreter exits. This is not a leak.
Subject: Re: [rt.cpan.org #98807] possible memory leaks
Date: Thu, 11 Sep 2014 12:11:05 -0700
To: bug-Moose [...] rt.cpan.org
From: Robert Messer <rmesser [...] intellisurvey.com>
Download (untitled) / with headers
text/plain 521b
Ok, thanks for the quick reply. I understand that Moose creates meta objects that live until the perl interpreter exits. But isn't the presence of the cycles still a bad thing? It means that even if you try to remove a meta-instance, it will hang around in memory unless you somehow manually remove or weaken the cycle, right? But I suppose that's ok, as long as you aren't creating tons of classes dynamically and expecting the old ones to go away. So I won't worry about it, and again thanks for the quick reply.
Download (untitled) / with headers
text/plain 324b
These meta objects are all effectively singletons, and they _must_ exist as long as the class exists. The cycles are not a problem, and they're not the cause of your memory leak _unless_ you are creating new (non-anonymous) classes on the fly for each web request. We do clean up meta objects for anonymous classes properly.
Subject: Re: [rt.cpan.org #98807] possible memory leaks
Date: Thu, 11 Sep 2014 12:16:33 -0700
To: bug-Moose [...] rt.cpan.org
From: Robert Messer <rmesser [...] intellisurvey.com>
Ok, thanks for the further explanation.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.