[resent to modperl list; earlier copy mistakenly cc'd to "p5p"]
Does anyone know what's causing the Apache::Request object to
leak here? See # XXX comment below:
package Apache::test;
sub Apache::Request::DESTROY{warn "DEAD: $_[0]\n"}
sub Apache::DESTROY{warn "Dead: $_[0]\n"}
Does anyone know what's causing the Apache::Request object to
leak here? See # XXX comment below:
package Apache::test;
sub Apache::Request::DESTROY{warn "DEAD: $_[0]\n"}
sub Apache::DESTROY{warn "Dead: $_[0]\n"}
use Devel::Peek;
use Apache::Request;
sub handle
Joe Schaefer wrote:
>>Somehow the assignment operator MUST be involved in the leak here.
>>(You only get a leak when the *same* reference (*SV) is on both sides
>>of the assignment).
>
>
> Could someone with modperl 1.2x built using a perl 5.8 release candidate
> please test this out:
I got t
Joe Schaefer <[EMAIL PROTECTED]> writes:
[...]
> Somehow the assignment operator MUST be involved in the leak here.
> (You only get a leak when the *same* reference (*SV) is on both sides
> of the assignment).
Could someone with modperl 1.2x built using a perl 5.8 release candidate
please tes
darren chamberlain <[EMAIL PROTECTED]> writes:
> * Joe Schaefer <[EMAIL PROTECTED]> [2002-07-09 12:47]:
> > Dave Rolsky <[EMAIL PROTECTED]> writes:
> > > On 8 Jul 2002, Joe Schaefer wrote:
> > > If I do this:
> > >
> > > my $x = shift;
> > > $x = make_something_from($x);
> > >
> > > then it s
* Joe Schaefer <[EMAIL PROTECTED]> [2002-07-09 12:47]:
> Dave Rolsky <[EMAIL PROTECTED]> writes:
> > On 8 Jul 2002, Joe Schaefer wrote:
> > If I do this:
> >
> > my $x = shift;
> > $x = make_something_from($x);
> >
> > then it seems like the original $x should go out of scope when it is
> > as
Dave Rolsky <[EMAIL PROTECTED]> writes:
> On 8 Jul 2002, Joe Schaefer wrote:
[...]
> > my $r = shift;
> > my $apr = Apache::Request->new($r);
> >
> > That's not going to leak, either. At least I hope not :-)
>
> I ended up using something like this and the leak went away.
>
> It seems to
On 8 Jul 2002, Joe Schaefer wrote:
> Write that like this, and I think your leak will
> disappear:
>
> my $r = Apache::Request->new( shift );
>
> AFAICT, Apache::Request::new is NOT leaking here, since the
> REFCNT of its returned object IS 1. There might be some
> magic-related bug in p
Dave Rolsky <[EMAIL PROTECTED]> writes:
[...]
> Here's some code that I think demonstrates the leak:
> package My::APRTest;
>
> use strict;
>
> use Apache::Request;
> sub Apache::Request::DESTROY{warn "DEAD: $_[0]\n"}
> sub handler
> {
> my $r = shift;
> $r = Apache::
On Mon, 8 Jul 2002, Richard Clarke wrote:
> "During the child exit phase, mod_perl invokes the Perl API function
> perl_destruct( ) to run the contents of END blocks and to invoke the
> DESTROY method for any global objects that have not gone out of scope
> already."
Notice where it says "..
Dave,
Perhaps this is why from the eagle book,
"During the child exit phase, mod_perl invokes the Perl API function
perl_destruct( ) to run the contents of END blocks and to invoke the
DESTROY method for any global objects that have not gone out of scope
already."
So I think i'm
It looks like there may be a memory leak with Apache::Request. I'm using
version 1.0 with Perl 5.6.1, mod_perl 1.26, and Apache 1.3.26. mod_perl
is statically compiled into Apache.
Here's some code that I think demonstrates the leak:
package My::APRTest;
use strict;
use Apache::Request
12 matches
Mail list logo
