[Bioperl-l] Memory leak in Bio::Root::Root?

Stefan Kirov skirov at utk.edu
Thu Dec 15 15:46:49 EST 2005


You should check find_cycle($self) and the same for seqobj. Also 
shouldn't it be
my $tempseq =   $seqobj->seq();
as opposed to
$tempseq =   $seqobj->seq();
I don't see anything wrong with the regexp (your next post).
Stefan


Mike Muratet wrote:

>
>
> On Wed, 14 Dec 2005, Stefan Kirov wrote:
>
>> My two cents: have you looked for cyclic referencing. Then your 
>> objects will not get destroyed properly. You can try Devel::Cycle to 
>> track those. If you post some more code we may have better idea what 
>> is going on.
>> Stefan
>>
>
> I included Devel::Cycle and tried find_cycle($polyn) and 
> find_cycle($nmer_statistics) but got no output. Can I assume that no 
> references were found?
>
> Here is the code for the max_polyn method:
>
> sub max_polyn {
>
>     my $seqobj;
>     my $_is_strict;
>     my $_is_instance = 1 ;
>     my $self = shift @_;
>     my $object_argument = shift @_;
>     my ($maxpolyn, $tempmaxpolyn, $polya,$polyc,$polyg,$polyt, 
> $tempseq , $lpolya, $lpolyc, $lpolyg, $lpolyt);
>
>
>     if (defined $object_argument) {
>         $_is_instance = 0;
>     }
>
>     # If we are using an instance object...
>     if ($_is_instance) {
>         if ($maxpolyn = $self->{'_max_polyn'}) {
>             return $maxpolyn;        # return count if previously 
> calculated
>         }
>         $_is_strict =  $self->{'_is_strict'}; # retrieve "strictness"
>         $seqobj =  $self->{'_seqref'};
>     } else {
>          #  otherwise...
>         $seqobj =  $object_argument;
>
>     #  Following two lines lead to error in "throw" routine
>         $seqobj->isa("Bio::PrimarySeqI") ||
>             $self->throw(" SeqStats works only on PrimarySeqI objects 
> \n");
>         # is alphabet OK? Is it strict?
>         #$_is_strict =  _is_alphabet_strict($seqobj);
>     }
>
>     $tempseq =   $seqobj->seq();
>     #$gccontent =   100 * ($gc_cnt =~ 
> tr/gcGC/gcGC/)/length($seqobj->seq());
>
>     $maxpolyn = 0;
>     my $lcount = 0;
>     my $polyn;
>     while ($lcount < length($seqobj->seq())) {
>
>     ($polyn = $tempseq)  =~ s/^\w{$lcount}(\w)\w*$/$1/;
>
>     if ($polyn=~/a/i) {
>         $lpolya++;
>          $lpolyc =  $lpolyg =  $lpolyt = 0
>     }elsif ($polyn =~/c/i) {
>         $lpolyc++;
>          $lpolya = $lpolyg = $lpolyt = 0;
>     }elsif ($polyn =~/g/i) {
>         $lpolyg++;
>         $lpolya = $lpolyc = $lpolyt = 0;
>     }elsif ($polyn =~/t/i) {
>         $lpolyt++;;
>          $lpolya = $lpolyc = $lpolyg = 0;
>     }
>     ($tempmaxpolyn ) = sort {$b <=> $a} $lpolya, $lpolyc, $lpolyg, 
> $lpolyt;
>     $maxpolyn = $tempmaxpolyn if ($tempmaxpolyn > $maxpolyn);
>     $lcount++;
>     }
>
>     my ($rmaxpolyn) = \$maxpolyn;
>     if ($_is_instance) {
>         $self->{'_max_polyn'} = $rmaxpolyn;  # Save in case called 
> again later
>     }
>
>     return  $rmaxpolyn;
> }
>
> Do you see anything that would create a memory leak?
>
> Thanks for the help
>
> Mike
>
>> Mike Muratet wrote:
>>
>>>
>>>
>>> Jason
>>>
>>>>
>>>> polyn returns a scalar object (blessed) or just some scalar data?
>>>> If you are really calling QStat->polyn( $obj) then 'new' is never 
>>>> called in the first place for the Qstat package.
>>>>
>>>
>>> polyn returns a reference to some scalar data. My understanding is 
>>> that 'new' would not be called, but then I'm at a loss to explain 
>>> where all the extra memory goes.
>>>
>>>> Destructors are automatic, but you can create your own to see 
>>>> when/if the destructor is called.
>>>> sub DESTROY {
>>>> my $self =shift;
>>>> warn("I am calling destroy in the Qstat object\n");
>>>> $self->SUPER::DESTROY;
>>>> }
>>>
>>>
>>>
>>> I will try this.
>>>
>>>> You can also inherit from Bio::Root::RootI and call bless on your 
>>>> own if you want to play with whether this is Bio::Root::Root 
>>>> induced behavior. I'm not sure I understand enough of how it works 
>>>> to tell you where else to look.
>>>>
>>>
>>> I will try this, too.
>>>
>>>> Is a new $seq_obj getting created every iteration of the loop?  Are 
>>>> these getting cleaned up or is Qstat keeping references  to them, 
>>>> and they are sticking around?  Devel::Cycle doesn't show any memory 
>>>> cycles?
>>>>
>>>
>>> A new $seq_obj gets created in every loop of the method that calls 
>>> QStats with the $seq_obj as an argument, but I undef it at the 
>>> bottom of the loop. Should this not be enough to get perl to recycle 
>>> the memory? I haven't tried Devel::Cycle but I will include it to 
>>> see what it says.
>>>
>>> I saw on some of the perl lists a reference to a memory leak in perl 
>>> 5.8 with the s/// operator. Have you heard about such a problem?
>>>
>>> Thanks for the help
>>>
>>> Mike
>>>
>>>> On Dec 13, 2005, at 11:32 AM, Mike Muratet wrote:
>>>>
>>>>> Greetings all
>>>>>
>>>>> I have a problem that surpasses what I know and what I've been 
>>>>> able to glean from perltoot,perboot,etc. Maybe it's a question for 
>>>>> a perl list, but here goes...
>>>>>
>>>>> I was given a package that calculates some statistics regarding 
>>>>> base repeats in a sequence. It inherits from Bio::Root::Root 
>>>>> presumbably to obtain the exception behavior bestowed by the class 
>>>>> judging from the perldocs and to enforce that the argument is a 
>>>>> PrimarySeq object. It has
>>>>> two methods which get called thus:
>>>>>
>>>>> my $polyn = QStat->polyn($seq_obj);
>>>>> my $nstat = QStat->nmer_stat($seq_obj);
>>>>>
>>>>> where the returned values are scalar references. The problem is 
>>>>> that script quickly uses up all of the 4GB address space 
>>>>> (processing lots of oligos) and crashes.
>>>>>
>>>>> I have used Devel::Size to determine the size of these variables 
>>>>> and get 3.8K and 7K. I have tried to undef them at the end of the 
>>>>> loop but it has no effect. I commented out the calls and the 
>>>>> problem goes away so the problem is associated with the QStat object.
>>>>>
>>>>> The QStat class has a constructor that calls the base constructor:
>>>>>     my $self = $class->SUPER::new(@args);
>>>>> would this demand a destructor somewhere?
>>>>>
>>>>> Does calling a method out of a class like this invoke all the 
>>>>> class machinery without creating the object with new?
>>>>>
>>>>> Can someone with experience deriving from Bio::Root::Root offer 
>>>>> some suggestions on how to get the memory back?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Mike
>>>>> _______________________________________________
>>>>> Bioperl-l mailing list
>>>>> Bioperl-l at portal.open-bio.org
>>>>> http://portal.open-bio.org/mailman/listinfo/bioperl-l
>>>>
>>>>
>>>>
>>>> -- 
>>>> Jason Stajich
>>>> Duke University
>>>> http://www.duke.edu/~jes12
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Bioperl-l mailing list
>>> Bioperl-l at portal.open-bio.org
>>> http://portal.open-bio.org/mailman/listinfo/bioperl-l
>>
>>
>>
>> -- Stefan Kirov, Ph.D.
>> University of Tennessee/Oak Ridge National Laboratory
>> 5700 bldg, PO BOX 2008 MS6164
>> Oak Ridge TN 37831-6164
>> USA
>> tel +865 576 5120
>> fax +865-576-5332
>> e-mail: skirov at utk.edu
>> sao at ornl.gov
>>
>> "And the wars go on with brainwashed pride
>> For the love of God and our human rights
>> And all these things are swept aside"
>>
>>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at portal.open-bio.org
> http://portal.open-bio.org/mailman/listinfo/bioperl-l


-- 
Stefan Kirov, Ph.D.
University of Tennessee/Oak Ridge National Laboratory
5700 bldg, PO BOX 2008 MS6164
Oak Ridge TN 37831-6164
USA
tel +865 576 5120
fax +865-576-5332
e-mail: skirov at utk.edu
sao at ornl.gov

"And the wars go on with brainwashed pride
For the love of God and our human rights
And all these things are swept aside"



More information about the Bioperl-l mailing list