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::Request->new($r);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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 perl that causes the assignment to bump
$r's refcount to 2. This MIGHT be circumventable with some better
code in Request.xs, but I really don't know how to fix it.
Until some perl guru enlightens us, as a personal rule I
try hard to avoid expressions like
$foo = make_something_out_of($foo);
I realize that this isn't always possible, but it often/usually
is. Such advice would serve you well in this case; you could
even get away with this
my $r = shift;
my $apr = Apache::Request->new($r);
That's not going to leak, either. At least I hope not :-)
HTH
--
Joe Schaefer
