Re: from the quick hacks department... x-bit controls mod_cgi
On Thu, 12 Apr 2001, Tim Bunce wrote:
On Wed, Apr 11, 2001 at 08:22:38PM -0700, Randal L. Schwartz wrote:
In an .htaccess, I place:
Options +ExecCGI
PerlFixupHandler "sub { -f $_[0]-filename and -x _ and
$_[0]-handler(q{cgi-script}) }"
Now any executable file in this directory (or below) is processed with
mod_cgi. Any non-executable file is processed with whatever the MIME
engine came up with before.
OK, too cool to not pass on. :)
Except that I think you'll find that string is being recompiled for
each request - slow and leaks memory. The principle is good though :)
Can you briefly explain why it leaks memory?
I have been playing with Apache::Leak and Devel::Leak trying to figure out
what is happening when Perl code leaks memory, but I haven't got my head
around it yet...
Also, a more general question to the list. How reasonable is it to assume
that most of the more standard modules on CPAN don't leak memory when used
in a mod_perl environment? For example DBI (not to pick on you Tim),
Data::Dumper, HTML::Parser or MD5 just to name some of the more common
modules. Are there any modules that I should stay away from when using
mod_perl?
- Cees Hek
Re: from the quick hacks department... x-bit controls mod_cgi
Can you briefly explain why it leaks memory? I haven't tried it, but I'm guessing it's creating a new anonymous sub on every request. I have been playing with Apache::Leak and Devel::Leak trying to figure out what is happening when Perl code leaks memory, but I haven't got my head around it yet... Most people don't get much useful information out of those modules. The things people think of as leaks are often not really leaks, so they don't show up with these (see below). Also, a more general question to the list. How reasonable is it to assume that most of the more standard modules on CPAN don't leak memory when used in a mod_perl environment? Totally unreasonable. Most module authors have not attempted to look for process growth over long periods of use. They may have tried to get rid of any circular references, but that's usually about it. Let's be clear about terminology: a real memory leak is a situation where a program discards some memory and fails to free it or reuse it. Perl has some of these, a few of which are documented here: http://language.perl.com/faq/v2/Q4.19.html Usually though, growth in size is not from a leak; it's just perl using more memory. There are some things to be careful of that are listed in the guide (passing large strings by value, slurping whole files into a single scalar, etc.). Note that lexical variables do not relinquish memory when they go out of scope, unless you manually undef them. Some growth will happen when the child processes use variables that were in copy-on-write memory from the parent process. How can you tell what's going on? If you hit your module 100 times, and then you hit it another 100 and it continues to grow, you may have an actual leak. If it stabilizes after the first 100, you just have normal growth. Don't expect to see growth on every hit; perl allocates memory in chunks and only grabs another chunk when it needs one. You can read some interesting stuff from Matt about finding memory leaks here: http://groups.yahoo.com/group/modperl/message/27908 http://groups.yahoo.com/group/modperl/message/27943 - Perrin
Re: from the quick hacks department... x-bit controls mod_cgi
On Wed, Apr 11, 2001 at 08:22:38PM -0700, Randal L. Schwartz wrote:
In an .htaccess, I place:
Options +ExecCGI
PerlFixupHandler "sub { -f $_[0]-filename and -x _ and
$_[0]-handler(q{cgi-script}) }"
Now any executable file in this directory (or below) is processed with
mod_cgi. Any non-executable file is processed with whatever the MIME
engine came up with before.
OK, too cool to not pass on. :)
Except that I think you'll find that string is being recompiled for
each request - slow and leaks memory. The principle is good though :)
Tim.
RE: from the quick hacks department... x-bit controls mod_cgi
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 12, 2001 11:27 AM
To: Tim Bunce
Cc: [EMAIL PROTECTED]
Subject: Re: from the "quick hacks" department... x-bit
controls mod_cgi
"Tim" == Tim Bunce [EMAIL PROTECTED] writes:
Tim On Wed, Apr 11, 2001 at 08:22:38PM -0700, Randal L.
Schwartz wrote:
In an .htaccess, I place:
Options +ExecCGI
PerlFixupHandler "sub { -f $_[0]-filename and -x _ and
$_[0]-handler(q{cgi-script}) }"
Now any executable file in this directory (or below) is
processed with
mod_cgi. Any non-executable file is processed with
whatever the MIME
engine came up with before.
OK, too cool to not pass on. :)
Tim Except that I think you'll find that string is being
recompiled for
Tim each request - slow and leaks memory. The principle is
good though :)
Well, then, untested:
..htaccess:
PerlFixupHandler Stonehenge::XBitCGI
Options +ExecCGI
$INC/Stonehenge/XBitCGI.pm
sub Stonehenge::XBitCGI::handler {
-f $_[0]-filename and -x _ and $_[0]-handler(q{cgi-script});
return -1;
}
Better? :)
s/finfo/filename/
;)
--Geoff
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. -
+1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and
open-enrollment Perl training!
RE: from the quick hacks department... x-bit controls mod_cgi
-Original Message-
From: Geoffrey Young
Sent: Thursday, April 12, 2001 11:41 AM
To: '[EMAIL PROTECTED]'
Cc: [EMAIL PROTECTED]
Subject: RE: from the "quick hacks" department... x-bit
controls mod_cgi
$INC/Stonehenge/XBitCGI.pm
sub Stonehenge::XBitCGI::handler {
-f $_[0]-filename and -x _ and $_[0]-handler(q{cgi-script});
return -1;
}
Better? :)
s/finfo/filename/
whoops - that should be reversed, of course *blush*
--Geoff
Re: from the quick hacks department... x-bit controls mod_cgi
"Tim" == Tim Bunce [EMAIL PROTECTED] writes:
Tim On Wed, Apr 11, 2001 at 08:22:38PM -0700, Randal L. Schwartz wrote:
In an .htaccess, I place:
Options +ExecCGI
PerlFixupHandler "sub { -f $_[0]-filename and -x _ and
$_[0]-handler(q{cgi-script}) }"
Now any executable file in this directory (or below) is processed with
mod_cgi. Any non-executable file is processed with whatever the MIME
engine came up with before.
OK, too cool to not pass on. :)
Tim Except that I think you'll find that string is being recompiled for
Tim each request - slow and leaks memory. The principle is good though :)
Well, then, untested:
.htaccess:
PerlFixupHandler Stonehenge::XBitCGI
Options +ExecCGI
$INC/Stonehenge/XBitCGI.pm
sub Stonehenge::XBitCGI::handler {
-f $_[0]-filename and -x _ and $_[0]-handler(q{cgi-script});
return -1;
}
Better? :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
