Hello everyone,
I've put HTML::Mason on a few servers now and have had problems with
Apache::Request and Apache::Test on two of them. My most recent is
having the problem and I'm about to go crazy if I don't figure out why
installs keep having problems.
Here's my setup: RH 7.2, Apache 1.3.27
I ran into the same problem. What I had to do was compile libapreq as a
shared library first. That solved things nicely.
HTH.
Regards,
S. G.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
On Sun, 24 Aug 2003, K Old wrote:
Hello everyone,
I've put HTML::Mason on a few servers now and have had problems with
Apache::Request and Apache::Test on two of them. My most recent is
having the problem and I'm about to go crazy if I don't figure out why
installs keep having problems
Ok, in the libapreq module I did the configure
./configure --with-apache-includes=/usr/includes/apache
make
make install
Everything compiled just fine.
Then did
perl Makefile.PL make make test make install
All of the tests still failed and the t/logs/error_log still reported:
[Sun Aug 24
had problems with
Apache::Request and Apache::Test on two of them. My most recent is
having the problem and I'm about to go crazy if I don't figure out why
installs keep having problems.
Here's my setup: RH 7.2, Apache 1.3.27, mod_perl 1.26, Perl 5.6.1 - all
installed from RPM's.
I did
On Mon, 25 Aug 2003, K Old wrote:
On Mon, 2003-08-25 at 00:18, Randy Kobes wrote:
On Sun, 24 Aug 2003, K Old wrote:
[ ... ]
I did a install HTML::Mason from the CPAN command
line and all the dependencies were downloaded and some
didn't compile. The two that didn't are
{require Apache::Request}) {
$newQ ||= sub { Apache::Request-new(@_) };
}
elsif (eval {require CGI}) {
$newQ ||= sub { CGI-new; };
}
else {
die Need CGI.pm or Apache::Request to operate;
}
--
But shouldn't
On 6 Jun 2003, K Old wrote:
[...]
Well, here are the errors I'm getting:
When I *force* and install of Apache::Request and a script calls
Apache::Request, this is in the error_log:
[Fri Jun 6 17:27:31 2003] [error] Can't locate object method new via
package Apache::Request at
/usr/lib/perl5
for about 3 hours.
. Glenn E. Bailey III
. Sprocket Data, Inc.
. http://www.sprocketdata.com
: -Original Message-
: From: Stas Bekman [mailto:[EMAIL PROTECTED]
: Sent: Thursday, July 31, 2003 6:48 AM
: To: K Old
: Cc: ModPerl List
: Subject: Re: Trouble with Apache::Request
:
:
: On 6 Jun
Message-
: From: Stas Bekman [mailto:[EMAIL PROTECTED]
: Sent: Thursday, July 31, 2003 6:48 AM
: To: K Old
: Cc: ModPerl List
: Subject: Re: Trouble with Apache::Request
:
:
: On 6 Jun 2003, K Old wrote:
:
: [...]
:
: Well, here are the errors I'm getting:
:
: When I *force* and install
Hi All,
perl-5.8.0 + mp1.99_10.
---
I am having problem trying to get /perl-status work.
It bombs out in Status.pm at the following location:
--
if (eval {require Apache::Request}) {
$newQ ||= sub
Tom Gazzini wrote:
I have a perl function which, amongst other things, needs to redirect
the request to another page.
It also needs to pass all the query parameters of the original request
(both GET and POST) to the redirected page, and also add one parameter
of it's own (an error message).
Sounds
Hi Joe --
+1. Scripting _inside_ the server opens up possibilities that
are unimaginable to folks who are content confining themselves
to the lowest common denominator (CGI).
Perhaps you could bullet-point a few of these possibilities for those of
us who are confined by our lack of
On Wed, 2003-07-02 at 22:36, Jesse Erlbaum wrote:
Hi Joe --
+1. Scripting _inside_ the server opens up possibilities that
are unimaginable to folks who are content confining themselves
to the lowest common denominator (CGI).
Perhaps you could bullet-point a few of these possibilities
Philippe --
Check out the guide:
Check out the books:
Check out the success stories:
Is that your answer? I was hoping for specific examples, not
hand-waving.
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
Jesse Erlbaum wrote:
Philippe --
Check out the guide:
Check out the books:
Check out the success stories:
Is that your answer? I was hoping for specific examples, not
hand-waving.
I like to think that Part III (Chapters 11-17) of the mod_perl Developer's
Cookbook does some of that.
why is Apache::Registry not sufficient to
handle all functions within an HTTP request but why is it bad to use
Apache::Request specifically for the content generation phase? Perrin had
some good practical reasons for this--caused by the generated-namespace,
sub-wrapped, eval'ed nature of Apache
It's unclear to me, though, that there are unimaginably
cool things you can get to in a real content handler that you can't get
to from an Apache::Registry script--which seems to be the assertion.
well, if you consider that you still get access to $r and all its treasures
from Apache::Registry,
On Wed, 2003-07-02 at 20:38, Andrew Ho wrote:
I totally agree with the fact that Apache::Registry can introduce many
hard-to-debug-problems. I've had enough headaches debugging some of these
issues myself. It's unclear to me, though, that there are unimaginably
cool things you can get to in a
are content confining themselves
to the lowest common denominator (CGI).
That said, apreq-dev is looking for someone to adopt and
develop the CGI port of libapreq-2/Apache::Request. I'm shooting
for a developer release of libapreq-2 before OSCON, and it'd be
_really_ cool if we had a functional CGI
]
|
| cc:
|
| Subject: Question about Apache::Request and query strings
Hector Pizarro [EMAIL PROTECTED] writes:
[...]
If the user closes the popup in the middle of an upload, Apache::Request
parse() isn't throwing any error, and all the following code in my module
savesthe file incomplete in the system, which of course is garbage data.
Is this a bug
.
If the user closes the popup in the middle of an upload, Apache::Request
parse() isn't throwing any error, and all the following code in my module
savesthe file incomplete in the system, which of course is garbage data.
Is this a bug, an incomplete feature, or is my configuration? If parse is
supposed
BTW, Apache::Request's 2.0 port is moving forward very fast thanks to Joe
Schaefer's efforts. He is looking for help, at least with testing the perl
glue. If you are interested to help, join the apreq-dev list:
http://httpd.apache.org/apreq/
On Fri, 7 Jun 2003, K Old wrote:
[ .. ]
Stas, thanks for your reply. I downloaded the CVS source and
it still failed all tests. Below is the output from make test
and the output from perl -V. Any help is appreciated!
Another thing that may be worth trying - if you've installed
libapreq, try
On Sun, 2003-06-08 at 01:50, Randy Kobes wrote:
On Fri, 7 Jun 2003, K Old wrote:
[ .. ]
Stas, thanks for your reply. I downloaded the CVS source and
it still failed all tests. Below is the output from make test
and the output from perl -V. Any help is appreciated!
Another thing that
On Sun, 8 Jun 2003, K Old wrote:
On Sun, 2003-06-08 at 01:50, Randy Kobes wrote:
On Fri, 7 Jun 2003, K Old wrote:
[ .. ]
Stas, thanks for your reply. I downloaded the CVS source and
it still failed all tests. Below is the output from make test
and the output from perl -V. Any
Hello everyone,
I'm having trouble getting Apache::Request installed on my Mandrake 9.0
system. Let me first say that I'm not using the Apache that came with
Mandrake 9.0. I downloaded Apache 1.3.27, mod_perl 1.27 and PHP 4.3.1
sources and compiled and installed them. Everything works fine
:
Did you do a threaded build of Perl 5.8.0?
You might try a non-threaded Perl build.
Regards,
Kitch
[EMAIL PROTECTED]
-Original Message-
From: K Old [mailto:[EMAIL PROTECTED]
Sent: Friday, June 06, 2003 11:27 AM
To: ModPerl List
Subject: Trouble with Apache::Request
Hello
Apache::Request installed on my Mandrake 9.0
[snip]
make test. I can force the install, but the same error comes up when I
try to load Apache::Request as a PerlModule in httpd.conf or when Alzabo
calls it.
Is it *exactly* the same error?
Any chance I should build perl without the threads
On Fri, 6 Jun 2003, K Old wrote:
Hello everyone,
I'm having trouble getting Apache::Request installed on my
Mandrake 9.0 system. Let me first say that I'm not using the
Apache that came with Mandrake 9.0. I downloaded Apache
1.3.27, mod_perl 1.27 and PHP 4.3.1 sources and compiled
if it works
Want to run that by me again??
Mandrake 9.0 (and several other linux distros) come out of the box with
Perl 5.8.0 built with threads. I'm guessing that having Perl compiled
with threads might be what's causing the problem in getting
Apache::Request installed.
I'm having trouble
make test
...
All tests successful.
This version will be soon released on CPAN, it wasn't released yet due to some
polishing of Apache::Test that is now used by Apache::Request for its test suite.
Here is how to get the cvs version:
% cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login
All,I'm
looking for some help with understanding how the Apache::Request objectsare
created and destroyed.I have the following params set in my
httpd.confKeepAlive OffPerlChildInitHandler
Bficient::Apache::DBloadWhich as I understand it should mean that an
apache::Request object iscreated
I have read that the param Method had been deprecated
$r-param('value'):
How do I get now the variables from a submitted form ??
regards Ewald
Ewald Geschwinde wrote:
I have read that the param Method had been deprecated
$r-param('value'):
How do I get now the variables from a submitted form ??
now? when? nothing has changed with Apache::Request. No April Fools jokes here
Apache::Request and CGI, so that you could switch
from one to another easily. I think this would be a big win for mod_perl
overall from the port your scripts quickly point of view.
I think a good compromise would be to keep the HTML generation code in an
entirely separate module, like Apache
of that?
The advantage is that
- you don't have to keep around two instances: $r and $q.
- assuming that CGI.pm-specific code is not used one can transparently switch
between Apache::Request and CGI.pm, by just changing:
$r = Apache::Request-new($r);
$r = CGI-new($r);
And of course Apache::Request
,
after re-blessing it.
Sounds interesting. What would be the advantage of that?
The advantage is that
- you don't have to keep around two instances: $r and $q.
- assuming that CGI.pm-specific code is not used one can transparently
switch between Apache::Request and CGI.pm, by just changing
transparent way to obtain the current request. Is there
no low-overhead way of getting at this?
Lincoln
On Thursday 13 March 2003 07:00 pm, Stas Bekman wrote:
One more issue with CGI.pm and mp2, and other modules as well.
CGI.pm is using Apache-request. The setting/retrieval of the global
request
of getting at this?
Not, under threaded mpm. Since the code should work the same with threaded and
non-threaded mpm, it's a problem for any 2.0 code. The problem with
Apache-request is that it involves storing and retrieving data from the TLS
(thread local storage), which is slow. So while
two instances: $r and $q.
- assuming that CGI.pm-specific code is not used one can transparently switch
between Apache::Request and CGI.pm, by just changing:
$r = Apache::Request-new($r);
$r = CGI-new($r);
And of course Apache::Request is a subclass of Apache ($r) and it works pretty
well
On 3/24/03 7:08 PM, Stas Bekman wrote:
In the future I can see someone extending Apache::Request to handle CGI.pm's
HTML generation in C, so the two could be replace each other.
I've always thought that HTML generation does not belong in CGI.pm, so I
don't see duplicating that functionality
Hello,
I use Apache::FakeRequest to test perl handlers without firing up Apache.
Testting is supposed to be done by matching output of handlers with some
regexps. But the print method of Apache::Request prints to STDOUT, so to
get output I applied following patch to it:
10c10,17
sub print
Andrew Alakozow wrote:
Hello,
I use Apache::FakeRequest to test perl handlers without firing up Apache.
Testting is supposed to be done by matching output of handlers with some
regexps. But the print method of Apache::Request prints to STDOUT, so to
get output I applied following patch
One more issue with CGI.pm and mp2, and other modules as well.
CGI.pm is using Apache-request. The setting/retrieval of the global request
record under threads is expensive, so the use of Apache-request is deprecated
in mp2.
If CGI.pm can be changed to optionally accept $r (as an argument
(Originally posted as Apache::Registry incompatible with CGI? by mistake
- sorry !)
Hi,
I have written a request handler in Perl. I recently changed some code
in this to convert
from using CGI within mod_perl to using Apache::Request. The old code
was ...
$DB-{ApacheReq} = shift;
:
$DB
I downloaded Apache::Request from CPAN and I have version 0.31. My C
compiler is gcc 2.96
aiya. libapreq 0.31 is the one that likes to append whatever it is that
one just uploaded to it to its heap until it starves your machine of memory,
if i recall correctly. it was fixed in 0.31_03 i believe
-BEGIN PGP SIGNED MESSAGE-
Hash: MD5
Does anyone know when this module might be released?
tia
lee
Lee Goddard mailto:[EMAIL PROTECTED]
What do people like to drink here, then?
The landlord looked sideways at his
On Fri, 31 Jan 2003, Lee Goddard wrote:
Does anyone know when this module might be released?
No, no one does. They are working on it. Use CGI.pm instead or revert to
mod_perl/apache version 1 until it is done.
- nick
Nick Tonkin {|8^)
Hi.
I use apache-1.3.26, modperl-1.27 and Embperl-1.3 with libapreq-1.0
and I have a routine in perl that processes the data passed from
a form (from the Modperl Cookbook):
use Apache::Request;
my $r = Apache::Request-instance(Apache-request);
foreach $param ($r-param
In the documentation of nodperl-2.0, I cannot find any references to
libapreq and $r-param.
correct me if I'm wrong anyone,but I don't think Apache::Request has been
ported to
modperl2 yet..
for now I'm using cgi
Steve wrote:
In the documentation of nodperl-2.0, I cannot find any references to
libapreq and $r-param.
Because it's not there yet.
correct me if I'm wrong anyone,but I don't think Apache::Request has been
ported to
modperl2 yet..
True. The C porting of libapreq is almost complete
Marc Lambrichs wrote:
Hi All,
I want to save my Apache::Request object in an PerlInitHandler called
Initialization and later on during the life cycle of the request call a
Initialization-get_request() method to use it again.
perldoc Apache::Request:
instance
Hi All,
I want to save my Apache::Request object in an PerlInitHandler called
Initialization and later on during the life cycle of the request call a
Initialization-get_request() method to use it again.
How can I do this in a safe manner? If you're wondering, why I would want
to do
Jesse Erlbaum wrote:
Hi Coexec --
I am experienced with using the CGI.pm, and now I want
to rewrite all of my CGI's using mod_perl and
Apache::Request.
Maybe a silly question: What are you hoping to gain by doing this?
Speed. Apache::Request's guts are implemented in C, CGI.pm is Perl
Hello all, I have been searching through the mailing
list archives for the answer to my question, but I
have not found it.
I am experienced with using the CGI.pm, and now I want
to rewrite all of my CGI's using mod_perl and
Apache::Request. According to everything that I have
been reading
On Tue, 19 Nov 2002, Coexec wrote:
Date: Tue, 19 Nov 2002 15:40:37 -0800 (PST)
From: Coexec [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Migrating from CGI.pm to Apache::Request question.
Hello all, I have been searching through the mailing
list archives for the answer to my question
Hi Coexec --
I am experienced with using the CGI.pm, and now I want
to rewrite all of my CGI's using mod_perl and
Apache::Request.
Maybe a silly question: What are you hoping to gain by doing this?
If you're already using Apache::Registry, then your CGI.pm apps are ALREADY
running
installation paths for required
packages.
-DeAngelo
-Original Message-
From: Perrin Harkins [mailto:perrin;elem.com]
Sent: Friday, November 08, 2002 1:10 PM
To: DeAngelo Lampkin
Cc: mod_perl Mailing List
Subject: Re: Can't locate object method new via package
Apache::Request (via Mason
List,
Can anyone tell me if a module exists that combines these two modules so
that, for example, when using Apache::Dispatch one can create an instance of
Apache::Request in the handler without clobbering the overridden methods
sent as part of the Apache::Filter object. Before I try and do
Hello,
We use this patch (on Apache::Filter 1.019) and it works ok. It won't
get you up and running with Apache::Registry, but it will do if you can
initialize the filter yourself.
Add this to Filter.pm:
sub Apache::Request::filter_register {
my $r= shift;
ISA = qw(Apache::Request
. Just ask this guy =
http://lists.fsck.com/pipermail/rt-users/2002-September.txt. It's the exact same
problem with the exact same error message, only in different clothing (he's having
trouble with the Apache::Cookie object rather than the Apache::Request object).
In the interest of full
Cool. Will do.
-Original Message-
From: Tim Tompkins [mailto:timt;arttoday.com]
Sent: Thursday, November 07, 2002 12:27 PM
To: DeAngelo Lampkin; [EMAIL PROTECTED]
Subject: Re: Can't locate object method new via package
Apache::Request (via Mason)...SOLVED
As a quick follow-up
DeAngelo Lampkin wrote:
And of course the other reason is that if the solution to the problem
was so obvious from the error message, somebody would have posted a
solution before I figured it out (with help from you guys).
There is documentation related to this problem in the troubleshooting
the information on http://www.masonhq.com
Hope this helps.
Gareth
-Original Message-
From: DeAngelo Lampkin [mailto:dlampkin;xencor.com]
Sent: 06 November 2002 23:25
To: [EMAIL PROTECTED]
Subject: Can't locate object method new via package Apache::Request
(via Mason)...
Hey guys,
You may
PerlHandler HTML::Mason::ApacheHandler
/FilesMatch
The reason this wasn't posted on a Mason mailing list is that this didn't seem like a
Mason problem per se and the Mason mailing list page specifically mentioned the Apache
Request object (at least in part the source of my problem)as being something
) for things like httpd.conf if you
want to keep it tidy.
Regards
Gareth
-Original Message-
From: DeAngelo Lampkin [mailto:dlampkin;xencor.com]
Sent: 07 November 2002 17:54
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Can't locate object method new via package
Apache::Request (via
Is Apache::Request installed for perl 5.8.0? Sounds like it's not loaded,
anyway.
Regards,
Tim Tompkins
--
Programmer
http://www.clipart.com/
http://www.rebelartist.com/
--
- Original Message -
From
You should pre-load Apache::Request anyway,
PerlModule Apache::Request
PerlModule HTML::Mason::ApacheHandler
FilesMatch \.msn$
SetHandler perl-script
PerlHandler HTML::Mason::ApacheHandler
/FilesMatch
Regards,
Tim Tompkins
November 2002 18:16
To: DeAngelo Lampkin; [EMAIL PROTECTED]
Subject: Re: Can't locate object method new via package
Apache::Request (via Mason)...
You should pre-load Apache::Request anyway,
PerlModule Apache::Request
PerlModule HTML::Mason::ApacheHandler
FilesMatch \.msn
/
--
- Original Message -
From: Gareth Kirwan [EMAIL PROTECTED]
To: Tim Tompkins [EMAIL PROTECTED]; DeAngelo Lampkin
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, November 07, 2002 11:20 AM
Subject: RE: Can't locate object method new via package Apache::Request
(via Mason)...
Tim
Thanks to Tim, Gareth, and Phillippe:
OK, I'll start with the solution to the problem and then drag on a bit for how I found
it.
The problem was the location of a shared object file for the Apache Request object. A
file called libapreq.so.1 was located in /usr/local/lib (should have been
As a quick follow-up, the PerlModule Apache::Request line is NOT needed in the
httpd.conf file for Mason to work. However, it was a very valuable debugging tool.
-Original Message-
From: DeAngelo Lampkin
Sent: Thursday, November 07, 2002 11:21 AM
To: Tim Tompkins; [EMAIL PROTECTED
As a quick follow-up, the PerlModule Apache::Request line is NOT
needed in the httpd.conf file for Mason to work. However, it was a very
valuable debugging tool.
That wasn't really the purpose, though. The purpose was to pre-load the
module in the parent apache process for efficiency. My
/i386-linux-thread-multi/auto/Apache/Request/Request.so'\
for module Apache::Request: libapreq.so.1: cannot open shared object file:\
No such file or directory [snip]
This isn't the most helpful error message in the world.
Huh?
It tells you EXACTLY what is wrong.
73,
Ged.
by Mason (a perl templating system), I get the
following error message:
[Wed Nov 6 11:56:20 2002] [error] Can't locate object method new via package
Apache::Request at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm line
878
Seems somewhat similar to a bug I've reported 10 months ago.
You might want to try to run the minimal testcase enclosed in the
forwarded mail.
Phil.
---BeginMessage---
I've found that mod_perl can get confused when dealing with method
calls during a redirect_internal phase:
1. page /1 uses
Hi all,
I am a newbie to mod_perl and going straight to mod_perl 2.
Have successfully written basic handler (API).
Have not installed mod_perl 1.x
Not using Apache::compat. ( Donot intend to use CGI.pm either )
In this case how to use methods from Apache::Request like $q-param() etc?
I can get
.
There were several related reports in the mailing list
during the
months: Apache::Request might not handle double-bytes or
utf8
correctly. Or it may be due to the C library.
You seem to know something about this issue. However,
this is the first
time I've seen utf8 discussed in relation
[EMAIL PROTECTED] writes:
[...]
With Kanji filename :
Size is 0
UPL:Content-Disposition=form-data; name=UPLOADFILE;
filename=.DOC
UPL:Content-Type=application/octet-stream
Without Kanji filename
Size is 306688
UPL:Content-Disposition=form-data; name=UPLOADFILE;
Please take a serious look. There were several related reports in the
mailing list during the months: Apache::Request might not handle
double-bytes or utf8 correctly. Or it may be due to the C library.
Peter
- Original Message -
From: Joe Schaefer [EMAIL PROTECTED]
To: [EMAIL PROTECTED
in the mailing list during the
months: Apache::Request might not handle double-bytes or utf8
correctly. Or it may be due to the C library.
You seem to know something about this issue. However, this is the first
time I've seen utf8 discussed in relation to Apache::Request on this list.
I've tried
Hi All-
We are using Apache::Request to handle our uploads
via the browser. Now that we switched to UTF-8 encoding
any filename with Kanji in the filename uploads with a
size of '0' and nothing goes to disk. Take the same file,
put its name to roman chars and it uploads fine. All other
On Mon, 26 Aug 2002, Ufuk Yuzereroglu wrote:
I dont know if this is the right place to ask but I just cant
install Apache::Request. When calling 'make', make cant find
any of the header files. Can anyone tell me where I did go
wrong?
Did you install mod_perl and apache successfully
Hi,
I dont know if this is the right place to ask but I
just cant install Apache::Request. When calling 'make', make cant find any of
the header files. Can anyone tell me where I did go wrong?
Thanks
UY
I'd like to access the original Apache startup environment variables from within Perl> sections.
Through experimentation and reading page 498 of the Eagle that I need to use Apache->Request->subprocess_env to access the original environment in order to do this, as %ENV is cleared at in
this out:
Perl
sub Apache::Request::DESTROY{warn DEAD: $_[0]\n}
sub Apache::DESTROY{warn Dead: $_[0]\n}
use Devel::Peek;
use Apache:Request;
package Apache::test;
sub handler {
my $r = shift;
my $apr = Apache::Request-new($r);
Dump($apr); # OK
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 the same
Does anyone know what's causing the Apache::Request object to
leak here? See # XXX comment below:
Perl
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
[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:
Perl
package Apache::test;
sub Apache::Request::DESTROY{warn DEAD: $_[0]\n}
sub Apache::DESTROY{warn Dead: $_[0]\n
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 perl
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 me
* 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
assigned to, so its
:
my $r = shift;
$r = Apache::Request-new($r);
my $r = shift;
$r = Apache::Request-new($_) for $r;
DOES NOT LEAK:
my $apr = Apache::Request-new(shift);
my $r = shift;
my $apr = $r; # $r and $apr have the same referent now right?
$apr = Apache::Request-new($r);
my $r = shift;
my
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
requests then this memory is
gonna be consumed by apache forever (at least until httpd is killed).
Richard
Dave Rolsky wrote:
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
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 ... for
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
I have a subrouting which returns references to
%r_info, %r_headers_hash and r_headers_list.
Part of %r_info is params from Apache::Request opbject $arq.
my %params;
foreach ($apr-param) {
$params{$_} = $apr-param{$_);
}
$r_info{'params'} = \%params,
however if this routine is called
1 - 100 of 343 matches
Mail list logo
