perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Johnson <solut...@gina.net>
Subject Re: Run away processes
Date Wed, 04 Apr 2001 23:58:17 GMT
So should the entry in the Guide be rewritten to:

sub UNIVERSAL::AUTOLOAD {
               my $class = shift;
                if ($UNIVERSAL::AUTOLOAD !~ /DESTROY$/) {
                   warn "$class can't $UNIVERSAL::AUTOLOAD!\n";
                }
             }

??????

Tim Tompkins wrote:

> You don't need to trap DESTROY calls.  But if you're defining an AUTOLOAD,
> you typically want to just return if the subroutine being called is DESTROY.
>
> Thanks,
>
> Tim Tompkins
> ----------------------------------------------
> Staff Engineer / Programmer
> http://www.arttoday.com/
> ----------------------------------------------
>
> ----- Original Message -----
> From: "Aaron Johnson" <solution@gina.net>
> To: <modperl@apache.org>
> Sent: Wednesday, April 04, 2001 2:48 PM
> Subject: Re: Run away processes
>
> > In a private email someone mentioned that removing the \ before the $
> might
> > make the messages more meaningful.  That code was copy and pasted from the
> > current guide so if it should be $ and no \$ in front of UNIVERSAL then
> Stas
> > might want to know :^)
> >
> > I changed it out and now it appears that it is all the DESTROY calls that
> > are making its way to the error log.  Should these be trapped some where
> > else?
> > I still don't think this has anything to do with my memory being consumed,
> > but I thought it seemed odd that so many things were called with no
> defined
> > sub.
> >
> > Aaron Johnson
> >
> > Aaron Johnson wrote:
> >
> > > Hello all,
> > >
> > > Having some hard ( for me ) to track memory usage issues. We have moved
> > > our production environment to a new machine with what we thought was
> > > plenty of memory, but we seem to have an erratic bit of code somewhere
> > > that eats all the available memory.  We did not have this problem on our
> > > previous machine, but it was running RH 6.1 and Perl 5.005 so by moving
> > > to RH 7.0 and Perl 5.6 we have really asked for trouble.
> > >
> > > My research shows that it might be in a search routine we have that
> > > calls in Swish-E, but we can't get a consistent run away process when
> > > testing.
> > >
> > > In "the guide" it is recommended that a sub in the startup.pl file:
> > > sub UNIVERSAL::AUTOLOAD {
> > >                my $class = shift;
> > >                warn "$class can't \$UNIVERSAL::AUTOLOAD!\n";
> > >              }
> > > to trap undefined sub routines might help find the problem.  I added
> > > that code and now I am getting a laundry list of "bad" calls.  Here is
> > > just a short list:
> > >
> > > Apache::ASP::Server=HASH(0x929ebc4) can't $UNIVERSAL::AUTOLOAD!
> > > Apache::ASP::Collection=HASH(0x91d3374) can't $UNIVERSAL::AUTOLOAD!
> > > Apache=SCALAR(0x8d61160) can't $UNIVERSAL::AUTOLOAD!
> > > Apache::ASP::GlobalASA=HASH(0x91d31d0) can't $UNIVERSAL::AUTOLOAD!
> > > Errno=ARRAY(0x8317564) can't $UNIVERSAL::AUTOLOAD!
> > > DBI::DBI_tie=HASH(0x83d1d64) can't $UNIVERSAL::AUTOLOAD!
> > > MLDBM::Serializer::Data::Dumper=HASH(0x917091c) can't
> > > $UNIVERSAL::AUTOLOAD!
> > >
> > > These are all repeated several times.  I ran the same
> > > UNIVERSAL::AUTOLOAD sub on another server and got very similar results (
> > > the older RH 6.1 and Perl 5.005 one ) so it seems the errors might be
> > > "normal" or at least under Apache::ASP.
> > >
> > > So the summary of my setup is:
> > > RH 7.0 ( with all RPM updates and new gcc )
> > > Perl 5.6
> > > Apache 1.3.19 compiled with the corrected gcc
> > > mod_perl 1.25
> > > Apache::ASP 2.09
> > >
> > > If any more info is needed let me know.
> > >
> > > Aaron Johnson
> >
> >


Mime
View raw message