Re: PerlAuthenHandler advice needed.
On Thu, 28 Sep 2000, Carlos Ramirez wrote:
$r-auth_name($realm), $r-auth_type($basic) did not work for me, which
is why I used the $r-header_out method. Also, after I set the outgoing
header and returned AUTH_REQUIRED, I got prompted but the $realm did not
show. Instead it displayed 'unknown' as the realm name. But when I set
the $r-status and sent out the response via $r-send_http_header and
returned AUTH_REQUIRED, the $realm name showed?
$r-auth_name($realm) works fine, provided you call
$r-note_basic_auth_failure, rather than
$r-header_out('WWW-Authenticate',...)
$r-auth_type did not become writeable until the patch i posted earlier.
I read the docs as i started this exercise and was aware of
$r-auth_name, $r-auth_type, but since they did'nt work and I kept
getting segfaults when using them I decided to try other routes. But
anyways I'm glad that I read the docs right and that you can indeed set
the AuthName using $r-auth_name.
until the recent change where $r-auth_type became writeable, and
get_basic_auth_pw/note_basic_auth_failure default AuthType to Basic if it
is not configured, those methods would segfault.
Re: Make test error!!
On Fri, 15 Sep 2000, [iso-8859-1] François Chenais wrote: Hello Using perl 5.6.0 apache_1.3.9 I 'm trying to build DSO mod_perl.1.24 = perl Makefile.PL USE_DSO=1 EVERYTHING=1 PERL_DEBUG=1 All is ok but "make test" says : --- ./apache_1.3.9/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c done /usr/local/bin/perl t/TEST 0 still waiting for server to warm up...not ok server failed to start! (please examine t/logs/error_log) at t/TEST line 95. make: *** [run_tests] Error 111 --- t/logs/error_log --- [notice] END block called for startup.pl [notice] Destruction-DESTROY called for $global_object [Fri Sep 15 10:34:40 2000] [warn] [notice] child_init for process 10374, report any problems to [no address given] --- is the server still running? check: % ps -flags | grep httpd or % netstat -a | grep 8529 or % telnet localhost 8529 if it core dumped, run (in the mod_perl-x.xx directory): % gdb ../apache-x.xx/src/htttpd (gdb) thttpd [if you get a core dump] (gdb) bt and post the output of that, along with your 'perl -V' and Makefile.PL options.
Re: Having difficulties with Tie::DBI and mod_perl
On Wed, 20 Sep 2000 [EMAIL PROTECTED] wrote: PerlFreshRestartOn try turning that Off. does DBI/DBD::mysql work for you without Tie::DBI?
Re: The case of the disappearing routine
On Thu, 21 Sep 2000, Chris Downes-Ward wrote: Dear all, We have a server which has a virtual server on it, this virtual server has a number of locations, one of which has a perl access handler defined, this server is a development server and is not heavily loaded. Every now and then (I wish I could be more precise) the entry point routine for the access handler "disappears". The error message in the log is "[error] Undefined subroutine routine name called". If I restart httpd the routine reappears. what does your mod_perl configuration look like?
RE: Apache::Request-new() problem
On Tue, 26 Sep 2000, Herrington, Jack wrote: I'm using Mason in process with mod_perl. I have also tried using mod_perl handlers direct with Apache::Request with no success. what do you see if you configure Apache::Status and open the url: /perl-status?Apache::Request ? also, any difference if you change Apache/Request.pm from: __PACKAGE__-mod_perl::boot($VERSION); to: DynaLoader::bootstrap(__PACKAGE__, $VERSION); ?
Re: mod-perl as DSO (solaris)
On Tue, 26 Sep 2000, Ricardo Stella wrote: Solaris 2.8 Apache 1.3.12 GCC 2.95.2 Perl 5.6.0 Enterprise 250 (64bitish) Modperl 1.24 I can't get modperl compiled as a DSO neither via the 'flexible-method' nor the APXS method. The first method, seg faults. The second method won't configure, stating I should not build mod-perl as a DSO or compile perl with -Ubincompat5005. My current perl was compiled with bincompat5005 (perl -V:bincompat5005 shows as 'defined') exactly, -Ubincompat5005 will _un_ define bincompat5005, perl -V:bincompat5005 should report: bincompat5005='undef'; this is a requirement for solaris (or any Perl where Perl's malloc is used, rather than system malloc) , because Perl's malloc with bincompat5005 will pollute malloc() and free() into the main server, then when mod_perl's dso is closed (it is closed/re-opened at startup), the everything in the main server using free/malloc now has a function pointer into la-la land. when you turn off bincompat5005, then Perl's malloc/free are namespace protected, so only Perl uses Perl's malloc.
Re: perl installation on hpux : cc vs gcc
On Tue, 26 Sep 2000, Dhananjay Naniwadekar wrote: I am trying to install perl-5.6.0 on hpux. It is choosing cc as the c compiler. I don't know why. If I install an earlier version of perl, it chooses gcc. I have an env-variable named CC which is set to gcc . try Configure -Dcc=gcc
Re: Why isn't PerlSetEnv working for me?
On Tue, 26 Sep 2000, Keith G. Murphy wrote: I'm running Apache 1.3.9 with mod_perl embedded, on Debian GNU/Linux. I have the following lines towards the end of my httpd.conf: PerlSetEnv PERL5LIB /usr/local/MyPerl/lib PerlRequire startup.pl Include perllocs.conf However, upon system startup, my startup.pl fails because it can't find a particular module in the @INC list. If I start Apache from the command line, it works. This is undoubtedly because PERL5LIB is set up in my /etc/profile, to the same path. I've looked at this until I'm crosseyed. Seemingly PerlSetEnv just doesn't work. Any ideas? Yes, I know the workaround: 'use lib' in startup.pl. But why? PerlSetEnv PERL5LIB works fine for me, and should work regardless of PerlTaintCheck, because mod_perl treats it special (note for the guide, stas). mod_perl-x.xx/t/conf/httpd.conf has this config: Location /perl/perl-status PerlSetVar StatusOptionsAll On SetHandler perl-script PerlHandler +Apache::Status PerlSetEnv PERL5LIB /home/dougm/lib/perl /Location which i can see as the last @INC entry printed by: /perl-status?inc
Re: Why isn't PerlSetEnv working for me?
On Wed, 27 Sep 2000, Keith G. Murphy wrote:
Upon further investigation, what I am seeing is that PERL5LIB gets
passed into %ENV just fine. It's just not being used to locate modules;
it is not in @INC. Could the part of Perl that pushes the PERL5LIB
setting to @INC have already executed prior to my PerlSetEnv statement?
i don't think so, it's set by mod_perl.c on every request, in
perl_per_request_init():
/* SetEnv PERL5LIB */
if (!MP_INCPUSH(cld)) {
char *path = (char *)table_get(r-subprocess_env, "PERL5LIB");
if (path) {
perl_incpush(path);
MP_INCPUSH_on(cld);
}
}
what version of mod_perl are you using?
Re: Apache::Status Memory Usage metrics
On Tue, 29 Aug 2000, Lyle D. Brooks wrote: This is my first time posting to this list, so forgive me if this question has been asked before (I did not see it in the archives or in the mod_perl guide). Apache::Status seems like a nice module, but I don't understand what the Memory usage section is telling me. For a given package, I have a function foo() that has a line like this. foo 48293 bytes | 1172 OPs Here's my questions... 1) 48293 bytes is what? Is that code?, stack?, data? or a combination of some of the three? TerseSize measures the sizeof() all structures (and strlen() of any strings) pointed to by the syntax (op) tree, lexical variables and globals. 2) 1172 OPs - what's an OPs? Is it good to have more or less? How does that affect memory usage? see matt's explanation. less is better. 3) Without changing the code, I can reload the memory usage page and the same function foo() will generally have the same number of bytes, but not always. The OPs always seem to remain the same number however. The bytes can vary but they don't seem to grow a great deal. Is this varying number a memory leak in the function? If not, what causes the number to vary from one invocation to the next? i'm not sure if stas has added a section to guide, but this has been explained a bunch of times here on the list. in a nutshell, Perl hangs onto many of the allocations your scripts makes, such as the first time a variable is used by a script (they are all NULL at compile time), string copies, array and hash sizes, scratch pads for things like join, concatination, etc. B-LexInfo includes a handler to show this behavior in action.
Re: PerlAuthenHandler advice needed.
On Thu, 28 Sep 2000, Todd Chapman wrote: Thanks Doug but I (and my customer) don't want to live on the CVS bleeding edge right now. Can you suggest something else? yeah, add this to httpd.conf: AuthType Basic
RE: Core file (debugging info turned on/stack trace)
On Tue, 26 Sep 2000, Shane Adams wrote: Well I did a little more investigation - it seems that we are dieing in Expat.pm line 451. The offending Function is: ... is this something you can reproduce at will? if you can give me a tiny test case that i can drop and i run, i'll take a look. As I recall, Doug, you helped me patch part of HTML::Mason dealing with typeglobs under an eval ... I believe that * is a typeglob in perl yes? right.
Re: NOT_FOUND from a PerlHandler causing problems with ErrorDocument
On 28 Sep 2000, Bjørn Ola Smievoll wrote: [Sorry for being so verbose, hope somebody still have the time and patience to read it all]. I have a setup where a PerlTransHandler registers a PerlContentHandler based simply on whether $r-uri ends with '.html' or not. The TransHandler does no verifying of the existence of the file, that doesn't happen until the ContentHandler kicks in. For an unsuccessful '-e' test, NOT_FOUND is returned from the ContentHandler. All this worked fine until I added an perl-based handler for the 404 using the ErrorDocument parameter in httpd.conf[1]. your error handler works fine for me with 404's. what is your PerlTransHandler doing?
Re: Why is Apache::PerlRun a subclass of Apache?
On Fri, 25 Aug 2000, Ken Williams wrote: ken, you're right, has-a relationship is the right way to go. your patch is perfect, applied, thanks!! i guess this will break some things, like Apache::RegistryLexInfo, but changes should be minimal and RegistryNG/PerlRun is still considered experimental-ish.
Re: Apache-request($r) broken?
On Thu, 24 Aug 2000, Ken Williams wrote:
Hi all,
It looks like setting Apache-request($r) doesn't work as documented. I
can't get it to install a subclass of Apache as the request object.
Here's some code in a handler:
_
warn "blessing $r into ", __PACKAGE__;
Apache-request($r = bless { _r = $r});
warn "\$r is $r";
warn "Apache-request is ", Apache-request;
_
And the result in the error logs:
_
blessing Apache=SCALAR(0x1401eaeb8) into Apache::Filter at ...
$r is Apache::Filter=HASH(0x140088028) at ...
Apache-request is Apache=SCALAR(0x1401fdab8) at ...
_
Notice that even after I call Apache-request($r), Apache-request still
returns an object blessed into the 'Apache' class, not the class of the
object I gave it.
it is broken in this respect, i just added this to ToDo:
- Apache-request($r) digs the request_rec out of $r regardless of the
type/class, e.g. Apache-request(bless {r = $r}, 'My::Apache')
with your PerlRun patch applied, your in no rush to have this fixed,
right?
Re: iconv/LD_PRELOAD question
how about using mod_so's LoadFile directive? On Thu, 28 Sep 2000, Rajit Singh wrote: To Whom It May Concern, I have a question with regards using LD_PRELOAD (or something more appropriate) to load libiconv_plug.so and override any other iconv implementation. (Would be grateful is someone can help). I'm running Apache with mod_perl 1.24 on Solaris 2.6. I'm using XML::Sablotron, and get it to convert to the iso-8859-1 character set. This isn't supported by default on Solaris, because its default iconv installation doesn't support Unicode (which is what Sablotron converts from). So I installed a new iconv implementation - and in the installation it advises using LD_PRELOAD=/usr/local/lib/libiconv_plug.so to override the default iconv implementation. When running my scripts under normal CGI circumstances I used SetEnv in httpd.conf in the Directory/ configuration to set LD_PRELOAD. When trying the script under mod_perl, I've tried a number of methods to get libiconv_plug.so to override the default iconv implementation to no avail. I've tried SetEnv (out of desperation... I already knew it wouldn't work) I tried compiling Sablotron with iconv_plug.so, but I figured that wouldn't work, 'cause then it's loaded after the default implementation I tried set LD_PRELOAD and then running apachectl. I tried setting LD_PRELOAD inside apachectl. Really... I'd be grateful if someone has an answer for this. Thanks in advance, Rajit
Re: Problem with Apache::SIG
On Thu, 28 Sep 2000, Bill Moseley wrote:
Is there a way to make that message go away?
maybe if you can give me a small example that reproduces the message. it
works fine for me:
shift-send_http_header;
print "hi\n";
exit;
print "bye\n";
nothing in the error_log.
actually, the patch below might fix it. lemme know.
--- src/modules/perl/perl_util.c2000/08/15 19:36:34 1.41
+++ src/modules/perl/perl_util.c2000/09/28 20:43:14
@@ -424,7 +424,7 @@
static I32
errgv_empty_set(IV ix, SV* sv)
{
-sv_setpv(sv, "");
+sv_setsv(sv, sv_no);
return TRUE;
}
Re: open - does not work
On Thu, 28 Sep 2000, Vsevolod Ilyushchenko wrote:
Hi,
Why does this script give no output under mod_perl, but works fine from the command
line:
#!/usr/bin/perl -w
use CGI;
print CGI-header();
open (AAA, "-");
because the C level stdout is not hooked up to the client. you can do
this as an alternative:
if ($ENV{MOD_PERL}) {
tie *AAA, 'Apache';
}
else {
open (AAA, "-");
}
Re: PerlSendHeader Off socket persistence (was Re: question: usingApache for non-HTML messages)
On Wed, 27 Sep 2000, B. Burke wrote: When I set PerlSendHeader to Off in my perl.conf it doesn't send headers, which is good. The bad part is that it seems to break socket persistence for some reason. When I have PerlSendHeader set to On, I can open a socket with my test client, and make multiple queries on the same socket. what is your test client? apache will close the connection after the first request, unless keep-alive is maintained between client/server.
Re: [WOT] MakeMaker
try DIR = []
Re: Patch for easy testing of Apache::* modules (resend)
On Mon, 17 Jul 2000, Ken Williams wrote: Hi all, Here's a resend of the Apache::test patch that I sent yesterday, this time sent as type text/plain from a Unix mailer. Rick Myers noted that the version I sent before was encoded with Macintosh BinHex, which is probably not the most appropriate choice for this list. ;-) looks great ken, applied, thanks! btw, when i first skimmed the patch, i thought it modified the mod_perl Makefile.PL test foo, which is why i was holding off.
$r-user vs. $r-connection-user
i've added an $r-user method as an alias to $r-connection-user, now that `user' hangs off of the request_rec rather than request_rec-connection in Apache 2.0 so by the time mod_perl-2.0 is ready to use, auth modules can work with both versions. for backwards compat you can use something like: use constant R_USER = $mod_perl::VERSION = 1.24_01; my $user = R_USER ? $r-user : $r-connection-user; which of course is optimized by the Perl compiler down to: my $user = $r-user; or my $user = $r-connection-user; for older versions. then again, by the time mod_perl-2.0 is ready you should be safe to say: use mod_perl 1.25; #require version 1.25 or higher my $user = $r-user;
Re: compiling mod_perl for solaris
On Fri, 1 Sep 2000, Joseph Sirucka - Netics wrote: Hi People I've been trying to compile mod_perl for solaris 8 recently and I recompiled perl 5.6.0 with _ubincompat5005 and -Uuselargefiles. But no matter what I do with with mod_perl to compile it at perl Makefile.PL blah i get this error ld.so.1: perl: fatal: relocation error: file /usr/local/lib/perl5/site_perl/5.6.0/sun4-solaris/auto/HTML/Parser/Parser.so: symbol perl_get_hv: referenced symbol not found Killed if you recompiled Perl with -Ubincompat5005, then you also need to recompile any xs site-perl modules, e.g. HTML::Parser
Re: further adventures with taint
On Mon, 4 Sep 2000, Michael Blakeley wrote: I've been running with AP616 and Taint On for three days now, and it seems to have fixed my problems. I hope so. I really hope so. still looking good? would be good to know if this isn't a problem on the mod_perl side :)
Re: Bug? in mod_perl when POST request yields REDIRECT
On Wed, 6 Sep 2000, Reif Peter wrote:
I am using a self written mod_perl module that does proxy requests. It acts
as content handler and fetches the requestet documents via LWP::UserAgent.
The program works fine but when the request is a POST request and the
response is a redirection (301, 302, ...) with a Location: header, no data
is sent to the browser.
If I don't read the postet data, everything works. So my suspicion is the
following:
For any reason, if the module returns a redirecting result code (301, 302,
...), mod_perl tries to read again the posted data and waits forever.
My solution is simple: Just set the Content-lengt: header to undef:
$r-header_in('Content-length' = undef);
Is this a bug or a feature?
it's a known issue, from the ToDo:
"- should $r-content unset $r-headers_in('content-length') ?
NOTE: im worried this could break apps who need to know content-length
after data has been read"
looking at mod_perl Changes:
=item 1.00b2 - 07/07/97
...
make compatible with 1.2.1 r-read_length change so we don't hang
on file uploads
the problem is that a drastic api change in Apache was made around that
time, which we had to fit into Perl's api. ap_setup_client_block() and
ap_should_client_block() are only supposed to be called once according to
the api spec. Apache.xs calls them everytime $r-read is called, and the
change above was setting r-read_length = 0; so ap_setup_client_block()
would return true the second time it is called. when a redirect or error
is thrown, ap_discard_request_body() also checks ap_should_client_block()
which returns true because we've set r-read_length = 0;
so, i think a reasonable fix for now is to localize the r-read_length
change with this patch:
Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.109
diff -u -r1.109 Apache.xs
--- src/modules/perl/Apache.xs 2000/09/27 16:25:56 1.109
+++ src/modules/perl/Apache.xs 2000/09/27 19:19:20
@@ -954,7 +954,7 @@
int bufsiz
PREINIT:
-long nrd = 0;
+long nrd = 0, old_read_length;
int rc;
PPCODE:
@@ -964,12 +964,15 @@
XSRETURN_UNDEF;
}
+old_read_length = r-read_length;
+r-read_length = 0;
+
if (should_client_block(r)) {
SvUPGRADE(buffer, SVt_PV);
SvGROW(buffer, bufsiz+1);
nrd = get_client_block(r, SvPVX(buffer), bufsiz);
-r-read_length = 0;
-}
+}
+r-read_length += old_read_length;
if (nrd 0) {
XPUSHs(sv_2mortal(newSViv((long)nrd)));
Re: Bug? in mod_perl when POST request yields REDIRECT
take 2 on that patch, this one adds a check so ap_setup_client_block() is
only called once. with this part of the fix you can call $r-content
multiple times without hanging:
my $data = $r-content;
$data = $r-content;
however, any calls to $r-content after the first will return undef.
(unless you happen to subclass and override the content method to cache
the read data somewhere)
Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.109
diff -u -r1.109 Apache.xs
--- src/modules/perl/Apache.xs 2000/09/27 16:25:56 1.109
+++ src/modules/perl/Apache.xs 2000/09/27 19:38:34
@@ -954,22 +954,27 @@
int bufsiz
PREINIT:
-long nrd = 0;
+long nrd = 0, old_read_length;
int rc;
PPCODE:
-if ((rc = setup_client_block(r, REQUEST_CHUNKED_ERROR)) != OK) {
- aplog_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO, r-server,
- "mod_perl: setup_client_block failed: %d", rc);
- XSRETURN_UNDEF;
+if (!r-read_length) {
+if ((rc = setup_client_block(r, REQUEST_CHUNKED_ERROR)) != OK) {
+aplog_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO, r-server,
+"mod_perl: setup_client_block failed: %d", rc);
+XSRETURN_UNDEF;
+}
}
+old_read_length = r-read_length;
+r-read_length = 0;
+
if (should_client_block(r)) {
SvUPGRADE(buffer, SVt_PV);
SvGROW(buffer, bufsiz+1);
nrd = get_client_block(r, SvPVX(buffer), bufsiz);
-r-read_length = 0;
-}
+}
+r-read_length += old_read_length;
if (nrd 0) {
XPUSHs(sv_2mortal(newSViv((long)nrd)));
Re: Passing STDIN to subprogram
On Wed, 6 Sep 2000, erich oliphant wrote:
I am replacing a CGI shell script with a modperl script. At one point in
the shell script subprogram is called. The HTML form that calls the script
calls it via a POST. As such the params are available via STDIN. The
subprogram call (which I can't eliminate yet) expects to see the form
params. However when I call it from the perl script STDIN is empty. I have
tried backticks and the open call (which are supposed to inherit STDIN) to
no avail.
STDIN cannot be passed to a subprocess, because STDIN is not stdin under
mod_perl. that is, it's not a file descriptor, it's just a Perl glob,
that's tie-d to the Apache request_rec + api. one solution would be to do
switch the POST to a GET:
local $ENV{PATH} = '/home/dougm/bin';
my $r = shift;
$r-send_http_header;
local $ENV{GATEWAY_INTERFACE} = 'CGI/1.1'; #hmm, shouldn't need todo this
local $ENV{QUERY_STRING} = $r-content;
local $ENV{REQUEST_METHOD} = 'GET';
local $ENV{CONTENT_LENGTH} = 0;
print `cgi-dump`;
where cgi-dump is:
#!/usr/local/bin/perl
use CGI ();
my $q = CGI-new;
print $q-as_string;
works just fine:
% POST http://localhost:8529/perl/post.pl
Please enter content (application/x-www-form-urlencoded) to be POSTed:
one=1
UL
LISTRONGone/STRONG
UL
LI1BR
/UL
/UL
Re: Problems loading POSIX module
On Wed, 30 Aug 2000, erich oliphant wrote:
Hi,
I have a script that bombs under modperl when it tries to 'use POSIX'. I
get the same message when I try to preload it in the httpd.conf. Here's the
error:
--
[Tue Aug 29 15:59:21 2000] [error] Can't load
'/usr/local/lib/perl5/5.6.0/sun4-solaris/auto/POSIX/POSIX.so' for module
POSIX: ld.so.1: httpd: fatal: relocation error: file
/usr/local/lib/perl5/5.6.0/sun4-solaris/auto/POSIX/POSIX.so:
symbolPL_stack_sp: referenced symbol not found at
can you post the output of the script below, run like so:
% perl perlnm.pl stack_sp POSIX
and your 'perl -V' too.
use Config;
my $sym = shift;
my @modules;
for (@ARGV) {
my $so;
for my $path (@INC) {
if (-e ($so = "$path/auto/$_/$_.so")) {
push @modules, $so;
last;
}
}
}
for ("$Config{archlibexp}/CORE/libperl.a",
"$Config{archlibexp}/CORE/libperl.so",
$Config{perlpath},
@modules)
{
next unless -e $_;
my $cmd = "nm $_ | grep $sym";
print "$cmd\n";
system $cmd;
}
Re: SIGSEGV
On Mon, 11 Sep 2000, [iso-8859-1] François Chenais wrote: Hello I have a Segmentation fault error with mod perl ! Any idea ? (gdb) run /opt/apache/lib/perl/WCM.pl Starting program: /usr/bin/perl /opt/apache/lib/perl/WCM.pl ... Program received signal SIGSEGV, Segmentation fault. that is not mod_perl, it's core dumping under your /usr/bin/perl #5 0x401b11f1 in ?? () from /opt/apache/lib/perl/PerlSWIP.so no doubt some buggy xs code in this module. if you have the sources, add this to Makefile.PL:WriteMakefile (OPTIMIZE = '-g') then the stacktrace will be more useful (my guess is that sv_setpv() is pass a Nullsv). if you're still stuck, [EMAIL PROTECTED] is the right place for help.
Re: /usr/lib/perl5/5.00503/i386-linux/CORE/perl.h:2546: redefinitionof `union semun'
On Wed, 13 Sep 2000 [EMAIL PROTECTED] wrote: Hi all, I have some problems with installig mod_perl, environment: Redhat 6.1 perl 5.005_03 (i386 from RPM) mod_perl-1.24 (source) apache-1.3.12 (source) In file included from mod_perl.h:92, from mod_perl.c:67: /usr/lib/perl5/5.00503/i386-linux/CORE/perl.h:2546: redefinition of `union semun' ... I found some docs about this problem: http://www.mail-archive.com/modperl%40apache.org/msg02400.html (removing rpm with perl and install it from source) http://www.mail-archive.com/dbi-users%40isc.org/msg00351.html (install DBI, I did it but still the same ) Have anyone any good idea?? Or similiar problem? your 'perl -V' might help. also, make sure you start over with freshly unpacked Apache and mod_perl trees now that your Perl has been re-intalled.
Re: Bad free() ignored?
On Wed, 13 Sep 2000, Eamon Daly wrote: We've been using mod_perl/DBI for our entire website for just under a year now (over 1.5M pages a day-- I owe the mod_perl folks a hell of a lot of beer), and have suddenly started seeing a small number of "Bad free() ignored" lines appear in the error logs. My error trapping gives line numbers, but they don't point to anything obvious. Has anyone else seen this behavior? if you shared the line numbers and a little about the code with us that would help. so would beer ;) the warning is something common to buggy xs code. mod_perl 1.26 1.26??
Re: segfaulting httpd :(
On Thu, 14 Sep 2000, Ben Turner wrote: hi all, this afternoon i compiled a fresh httpd (apache 1.3.12), together with mod_perl 1.24. i'm on Solaris 8, running perl 5.6.0. after compiling httpd, i'm getting segfaults whenever i do a normal http request. for instance: stacktrace would help (see SUPPORT for hints). also, your 'perl -V' and Makefile.PL options.
Re: modperl and mutiple Servers
On Wed, 20 Sep 2000, Tobias Dittrich wrote: Hi, I am running Apache Server with mutiple hosts (IP as well as name based) on a SuSe Linux 6.4 machine. Some of the hosts are running modperl scripts as well as perl scripts at the same time and they do share the same global variables (such as Database login/ password etc.) defined in a perl script that is "required" in ervery script. These hosts are almost identical as they are mostly the same webshop in different languages but do reside in different directories. Now I am experiencing some strange behavior: sometimes one of the hosts is using the variables of another host. For example the german site logs into the database as "the english site" and then displays its contents in english instead of german. After pressing the reload button the correct content is being displayed. So my question now is: is it possible that this error is caused by modperl because all of the scripts have the same scriptnames (even though they do come from different diretories) and that they are being mixed in memory? And how could I avoid this without having to rename all of the scripts? I did not find anything in the documentation/ FAQs of modperl/ Apache but maybe someone could point me to a doc about modperl/ Perl where this topic is being covered? it is possible if your mod_perl is older than version 1.23, what version are you using? it's an old bug that should be gone for good in 1.23, i hope it hasn't crept up again.
Re: Core Dump on use DBI
On 20 Sep 2000 [EMAIL PROTECTED] wrote: I did the same thing (static linking) and it now also works. FYI, I was using the Apache httpd out of the box from Redhat. It had been compiled with http_core, mod_so and no other modules. All modules (including mod_perl) were dynamically loaded in the httpd.conf file. I have a feeling that the bug only exists with DSO's. redhat used to ship a mod_perl dso rpm older than mod_perl-1.22, not sure what versions of things they're at now. 1.22 fixed a but a bug related to pre-loading xs modules, e.g. DBI.
Re: Can't locate object method No via package such
On 25 Sep 2000, Alan E. Derhaag wrote: Good try, but /dev/null is not broken on my machine. ok, i have seen this happen at least once in the past, glad it's not a common problem. looking back now at some other mod_ssl fixes for 'make test', i'm reading that mod_ssl has some sort of problem with /dev/null. i don't know the details, but maybe this patch will fix the problem for you. however, we had switched from -e0 to /dev/null in mod_perl-1.17, something todo with suexec/setuid, which i think will still be a problem looking at perl.c: if (PL_euid != PL_uid || PL_egid != PL_gid) Perl_croak(aTHX_ "No -e allowed in setuid scripts"); --- src/modules/perl/mod_perl.c 2000/09/01 05:23:17 1.126 +++ src/modules/perl/mod_perl.c 2000/09/26 17:03:39 @@ -668,7 +668,7 @@ #ifdef WIN32 argv[argc++] = "nul"; #else -argv[argc++] = "/dev/null"; +argv[argc++] = "-e0"; #endif MP_TRACE_g(fprintf(stderr, "perl_parse args: "));
Re: Apache::Request-new() problem
On Mon, 25 Sep 2000, Herrington, Jack wrote:
I have the same problem as one of the previous reporters with
Apache::Request-new(). The problem occurs whether I call it after a 'use'
or after a 'PerlModule' load. Perl returns the no 'new' method could be
found for Apache::Request.
sounds to me like your script is not running under mod_perl.
Apache/Request.pm calls this to bootstrap the xs interface:
__PACKAGE__-mod_perl::boot($VERSION);
if you are not running under mod_perl ($ENV{MOD_PERL} is not set), then
the interface is not bootstrapped. this is done so 'perl -c' can be run
on scripts that 'use Apache::*' with apis only available when running
inside the server.
Re: It just stopped work...
On Tue, 26 Sep 2000, Luis 'Champs' de Carvalho wrote: [Tue Sep 26 10:50:43 2000] [error] Can't locate object method "schema" via ^ package "URI::http" at /usr/local/lib/site_perl/URI/WithBase.pm line 48. line 48 is an AUTOLOAD routine: $self-[0]-$method(@_); looks like your code is calling '$uri-schema', rather than '$uri-scheme'
Re: Value of ErrorLog directive via mod_perl
On 26 Sep 2000, Bjørn Ola Smievoll wrote: I want to return the last 5 lines or so of the error_log each time there's a 500 error. The faculty and students ordinarily don't have access to the error log, so it will be helpful for them to see the last lines from the log file to help them fix problems with their documents (mostly wrong file perms and stuff like that). I could hardcode the value, but since we distribute our server package to well over 50 servers, some running multiple virtualhosts, I doubt that would work very well. ok, that does sound useful. i've committed the patch to cvs.
Re: question: using Apache for non-HTML messages
On Mon, 25 Sep 2000, B. Burke wrote: I've been able to basically remove the response headers by removing the functionality of ap_sen_header_field() before compiling Apache, but it would be nice to you don't have to remove anything, just don't call $r-send_http_header and make sure PerlSendHeader is configured to Off, then Apache will not send any headers.
Re: Apache::DB in emacs
On 24 Sep 2000 [EMAIL PROTECTED] wrote: Can anyone tell me if there is a way to run mod_perl's Apache::DB under emacs? there are some 'remote' hooks in the Perl debugger (perl5db.pl), but i've only heard about it, never tried, so not sure if that is a possible solution. i don't think Apache::DB as-is will run under emacs, unless somebody with enough emacs-lisp-fu can rig something up to run 'httpd -X -DPERLDB' under emacs.
Re: Solution for: Re: $ENV{PATH} set by mod_perl script affectsmod_cgi scripts
On Tue, 6 Jun 2000, Ben Cohen wrote:
This was certainly a weird bug ( I think it was a bug ).
Even setting PerlSetEnv in httpd.conf didn't help.
The PATH would be properly set until the first time a mod_perl
script modified its PATH at which point all other
scripts including mod_cgi scripts would 'inherit' this
new PATH.
you should be able to cure this simply by localizing:
local $ENV{PATH} = "/bin:/usr/local/bin";
is that not the case?
Re: subprocess_env
On Thu, 8 Jun 2000, Ian Kallen wrote:
I'm using a third party module that writes a bunch of variables to the
subprocess_env table to setup data for the request. It has us making
repeated class method calls like this (for our usage with Mason):
% Blah::foo('bletch') %
where foo is in the Blah package merely doing this:
sub foo {
my($s) = @_;
my($r) = Apache-request();
return $r-subprocess_env('foo_' . $s);
}
I'm thinking of changing the behvior to
% $ENV{'foo_bletch'} %
but foo_bletch isn't in the %ENV hash, so I'm looking at initializing
every request to do this:
$r-subprocess_env-do(
sub { my($k,$v)=@_;
$ENV{$k}=$v;
1;
}
);
to eliminate repeated accesses of the subprocess_env table; one call
populates %ENV and that's it.
Now, I don't want to kick off a debate on the performance problems that
reading/writing to the environment incur; I didn't design this behavior
I just want to make the best of it since this is what the application
requires of us. I just need to optimize access to the environment by
turning the dozen or so calls per request to Blah::foo to just %ENV.
Any ideas regarding the expense of mulitple $r-subprocess_env vs.
accessing %ENV?
%ENV will probably be faster for lookups, since subprocess_env has the
overhead of calling a perl subroutine (pp_entersub). it's the population
of %ENV that can be expensive. you might be better off populating a
non-magic global, such as %Env.
RE: PerlAddVar bug
On Thu, 6 Jul 2000, Geoffrey Young wrote:
I guess my expectation is that $r-dir_config('MyVar') and
$r-dir_config-get('MyVar') should inherit equally, which as far as I can
tell, they don't. PerlSetVar or PerlAddVar - it makes no difference.
the problem is related to the Apache::Server-dir_config support. in the
directive handler, if path was NULL, the var was set/add-ed only to the
server_rec-module_config. $r-dir_config falls back to the
server_rec-module_config if the var is not found in
request_rec-per_dir_config, but $r-dir_config-get does not. the patch
below fixes the problem, works just as PerlSetEnv does. the key/val is
always added to the per-dir table, and also added to the per-server table
is path == NULL, for use at startup time.
p.s.
i also just committed a change so PerlAddVar is now an ITERATE2 rather
than TAKE 2, so you can say:
PerlAddVar Key val-one val-two val-three
Index: src/modules/perl/perl_config.c
===
RCS file: /home/cvs/modperl/src/modules/perl/perl_config.c,v
retrieving revision 1.102
diff -u -r1.102 perl_config.c
--- src/modules/perl/perl_config.c 2000/09/22 18:52:00 1.102
+++ src/modules/perl/perl_config.c 2000/09/26 18:29:51
@@ -717,17 +717,17 @@
CHAR_P perl_cmd_var(cmd_parms *cmd, void *config, char *key, char *val)
{
+perl_dir_config *rec = (perl_dir_config *)config;
MP_TRACE_d(fprintf(stderr, "perl_cmd_var: '%s' = '%s'\n", key, val));
-if (cmd-path) {
-perl_dir_config *rec = (perl_dir_config *) config;
-if (cmd-info) {
-table_add(rec-vars, key, val);
-}
-else {
-table_set(rec-vars, key, val);
-}
+
+if (cmd-info) {
+table_add(rec-vars, key, val);
}
else {
+table_set(rec-vars, key, val);
+}
+
+if (cmd-path == NULL) {
dPSRV(cmd-server);
if (cmd-info) {
table_add(cls-vars, key, val);
Re: dir_config and Apache::Table confusion
On 26 Sep 2000, Bjørn Ola Smievoll wrote: Works for me too when PerlSetVar is inside a Location /foo, but not when it's defined outside, in the 'root' of httpd.conf. Is this how it should be? From the documentation in 'Writing Apache Modules ..' it doesn't seem like it is, at least not to me. ah, see the patch i just posted, it should fix this problem too.
Re: Apache::DProf tip
On Sat, 10 Jun 2000, Perrin Harkins wrote: Here's something that might be obvious to others but took me a while to figure out: If you want to get useful profiling information, you need to initialize the debugger before your modules get compiled. If you pull in your modules from startup.pl, you can accomplish this by putting a block like this in your httpd.conf before the "PerlRequire startup.pl" statement: Perl use Apache::DProf; use Apache::DB; Apache::DB-init; /Perl The "PerlModule Apache::DProf" directove suggested in the Apache::DProf docs also seems to work, but be careful because load order seems to matter here. the Apache::DB docs explain this: =item init This function initializes the Perl debugger hooks without actually starting the interactive debugger. In order to debug a certain piece of code, this function must be called before the code you wish debug is compiled. -- it should probably be made more clear though, maybe a comment in the config example.
Re: env in background process
On Mon, 14 Aug 2000, Niraj Sheth wrote:
Hi,
I am having very strange problem with environment variables.
From Apache::PerlRun script(cgi) I am setting env and firing background
process ..
system("$command ") (or print `$command `;)
now looks like environment variable being persistence b/w different
requests ONLY in background process. so it's looks to me that mod_perl
is setting proper "Perl Level" env but failing to reset env at "c level"
or "process level". I know it's sounds very weird.
/perl-status?env is printing correctly but my background process
($command) is printing few extra env, which i set it in different cgi
script.
e.g. "script1.pl" is setting $ENV{foo1} = "foo1" and firing print
`command1 `;
and "script2.pl" is setting $ENV{foo2} = "foo2" and firing print
`command2 `;
after few hits both env(foo1 and foo2) are visible to both background
processes.
while /perl-status?env is displaying correctly.
Here command1 and command2(perl scripts) are just printing env
Apache/1.3.9 (Unix) mod_perl/1.21
with the test case below, i get the expected results:
env is missing MOD_PERL
all of %ENV should be inherited except for this one. if you have a
small test case that i can drop in and run (small like the one below),
i'll take a look.
my $r = shift;
$r-send_http_header;
local $ENV{PATH} = '/usr/bin';
$ENV{PACKAGE} = __PACKAGE__;
my @env = `env`;
my %env;
for (@env) {
chomp;
my($k,$v) = split '=';
$env{$k} = $v;
}
while (my($k,$v) = each %ENV) {
next if exists $env{$k};
print "env is missing $k\n";
}
Re: Multiple PerlAccessHandlers problem.
On Tue, 15 Aug 2000, Trevor Phillips wrote: I'm having problems with a mix of PerlAccessHandlers. I have two handlers, and it is required that one be defined in a Location block, and the other currently in .htaccess' as required. The problem is that the one in the .htaccess is being completely ignored when I have the one in the Locate block. ie; In httpd.conf: Location / PerlAccessHandler XXX /Location In a .htaccess: PerlAccessHandler YYY So, XXX takes effect, but YYY is ignored. If I take out the Location one and have both in the .htaccess: PerlAccessHandler XXX YYY Or even on separate lines: PerlAccessHandler XXX PerlAccessHandler YYY Then it all works, but when XXX is in a Location, it overrides all .htaccess references. Is this supposed to be the correct behaviour? How do I get the behaviour I want? (One in a Location, and one in .htaccess). it is the expected behavior, the config merge routine just checks if the new config Perl*Handler array exists, if so, uses that, otherwise points at the base config Perl*Handler array. it does not attempt to merge the values of both arrays. it was in the ToDo file at one point to merge the arrays as you expected, but it now lives in the 2.0 ToDo file.
RE: env in background process
On Tue, 15 Aug 2000, Niraj Sheth wrote:
so why dump_env is getting both?
If I either uncomment "local %ENV = %ENV;" in script or put "%ENV = ();"
in PerlCleanupHandler then dump_env is working fine.
I tried both Apache::PerlRun and Apache::Registry which same result.
oh whoops, you did send a test case. i think the problem is that mod_perl
only clears the Perl side of %ENV, so the underlying C environ array is
not modified. if we do that than other problems pop up. the best
approach for the moment is to use:
local $ENV{FOO1} = 'foo1';
print `dump_env`;
Re: Strange exit error
On Sat, 19 Aug 2000, Ron Pero wrote:
Am running
In PerlRun
$ENV{MOD_PERL} = mod_perl/1.21
This is perl, version 5.005_03 built for i386-freebsd
It is on iserver, which has a virtual root system
Am also running dbi.
When the script calls "exit", it produces an error:
at /usr/local/etc/httpd/cgi-bin/myscript.cgi line 366.
line 366 is the line that contains "exit".
There is no descriptive clue as to what the error is.
This does not happen while running the script in cgi mode.
I've looked in the mod_perl guide, and tried different ways of exiting
(Apache::exit, etc), but same thing. And besides, exit should work just
fine under PerlRun.
Can anyone clue me in as to what this very cryptic error is?
it's been explained a few times in the past, i don't feel like doing it
again or searching the docs/archives. in short, calling exit() is bad,
avoid it. Apache::exit overrides the builtin exit() to prevent some
of the badness, but in a way that can be tripped up leading to that
warning message. it is only a warning, if you want to get rid of it,
don't use exit().
Re: Building modperl as a DSO in Apache_1.3.12
On Tue, 22 Aug 2000, Kairam, Raj wrote: I am trying to build modperl ( mod_perl-1.24 ) as DSO in to Apache ( apache_1.3.12 ) on a host running HP-UX 11.0 ld: Unrecognized argument: -Wl -E ld: Usage: ld flags ... files ... The output of make is captured in the following attachment make_0818.txt The last line in the above file indicates the 'ld' command and the arguments '-Wl -E' are in that long line halfway. When I look at the generated Makefile, I see the two lines CCCDLFLAGS = +z CCDLFLAGS = -Wl, E -Wl,-B,deferred How can I avoid this error ?. Any of you working with mod_perl on a HP-UX box encountered this situation ?. your 'perl -V' would help alot, but i'm guessing if you run 'make LD=cc', that would fix the problem.
RE: PerlAddVar bug
On Tue, 26 Sep 2000, Geoffrey Young wrote: groovy - the patch seems to work just fine (you've been busy, it seems :) cool! p.s. i also just committed a change so PerlAddVar is now an ITERATE2 rather than TAKE 2, so you can say: PerlAddVar Key val-one val-two val-three that works ok too. Any particular reason for keeping PerlSetVar TAKE2? not that i can think of, it should have been ITERATE2 the first time around.
Re: PATCH: AIX build fix for the apaci style build
On Thu, 24 Aug 2000, Jens-Uwe Mager wrote: Well, I have only used the apxs DSO style build previously and did not notice that for linking modperl statically into httpd (apaci style) there are small problems due to the AIX specifix .exp file business. The following patch fixes this, in particular it adds the mod_perl.exp file as an export file while httpd is linked to export the extra symbols from modperl needed by libapreq and Embperl. It also adds logic to Apache::src to find the httpd.exp if modperl is not a DSO. applied, thanks! While doing that I noticed that mod_include if built as DSO for PERL_SSI needs to reference the perl symbols but the build procedure does only reference the httpd.exp file and not the perl.exp file, so this will not work yet. I had to use a config like this: perl Makefile.PL EVERYTHING=1 DO_HTTPD=1 USE_APACI=1 \ APACI_ARGS="--enable-module=most --enable-shared=max --disable-shared=perl --disable-shared=include" you should also be able to use PERL_SSI=0 hmm, Makefile.PL could probably detect if mod_include is static or not, i'm not sure it's worth it though.
Re: PerlModule in .htaccess (for auth) faults (possible patch forperl_config.c)
On 22 Aug 2000, Andrew Gideon wrote:
...
My .htaccess file contains:
PerlModule Apache::TAGXSessionAuth
PerlAuthenHandler Apache::TAGXSessionAuth-authen
PerlAuthzHandlerApache::TAGXSessionAuth-authz
After attaching to a child process and getting the segv,
the stack looks like:
(gdb) where
#0 0x107810 in ap_push_array ()
thanks for digging into this andrew.
i think the problem is related to the perl_merge_server_config routine:
#if 0
/* We don't merge these because they're inlined */
mrg-PerlModule = append_arrays(p, add-PerlModule, base-PerlModule);
mrg-PerlRequire = append_arrays(p, add-PerlRequire, base-PerlRequire);
#endif
this means that VirtualHost configs have NULL for both arrays. this is
fine at startup time, since mod_perl only uses the base_server config.
a simple fix is to not push if either is NULL:
Index: src/modules/perl/perl_config.c
===
RCS file: /home/cvs/modperl/src/modules/perl/perl_config.c,v
retrieving revision 1.103
diff -u -u -r1.103 perl_config.c
--- src/modules/perl/perl_config.c 2000/09/26 20:05:22 1.103
+++ src/modules/perl/perl_config.c 2000/09/26 20:59:48
@@ -587,8 +587,11 @@
return NULL;
}
}
-*(char **)push_array(cls-PerlModule) = pstrdup(parms-pool, arg);
+if (cld-PerlModule) {
+*(char **)push_array(cls-PerlModule) = pstrdup(parms-pool, arg);
+}
+
#ifdef PERL_SECTIONS
if(CAN_SELF_BOOT_SECTIONS)
perl_section_self_boot(parms, dummy, arg);
@@ -618,7 +621,9 @@
}
}
-*(char **)push_array(cls-PerlRequire) = pstrdup(parms-pool, arg);
+if (cls-PerlRequire) {
+*(char **)push_array(cls-PerlRequire) = pstrdup(parms-pool, arg);
+}
#ifdef PERL_SECTIONS
if(CAN_SELF_BOOT_SECTIONS)
Re: Apache::DProf tip
On Tue, 26 Sep 2000, Perrin Harkins wrote: On Tue, 26 Sep 2000, Doug MacEachern wrote: the Apache::DB docs explain this: The connection between Apache::DProf and calling something in Apache::DB was not obvious to me until I thought about how DProf works. yeah, i was actually surprised to find that it was documented anywhere ;) I'd be happy to write up a little documentation patch for it. I'll send it to you. that'd be great, thanks!
Re: make tar_Apache broken?
On Wed, 30 Aug 2000, Jesse Erlbaum wrote: Hey Doug mod_perl'ers! I tried to build mod_perl and use "make tar_Apache" to build a distributable tar for other same-architecture machines, without success. ... If this is correct, and not an artifact of trying to build outside of the normal paths, this would seem to indicate that there is a small flaw in the Makefile.PL which references the wrong directories. If that is the case, I have created a patch which appears to correct the problem: applied, thanks!
Re: Apache::ASP rand, srand and fork...
On Tue, 19 Sep 2000, Joshua Chamas wrote:
Perhaps I should auto init srand() then for Apache::ASP
to make sure that its happening post fork? Something like
if(! DONE FOR CURRENT PID) {
srand();
}
For reproducability within Apache::ASP, all that has to
happen is someone initializing it to srand(something)
in one of their scripts.
This idea though I think would do well to be bundled
into modperl itself. Doug, what do you think?
how about this patch which will override the builtin srand with a noop
(Apache::srand) and call CORE::srand once per-child during child_init.
Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.108
diff -u -r1.108 Apache.xs
--- src/modules/perl/Apache.xs 2000/09/13 07:50:11 1.108
+++ src/modules/perl/Apache.xs 2000/09/25 19:15:51
@@ -540,6 +540,12 @@
Apache_terminate_if_done(r,sts);
perl_call_halt(sts);
+void
+srand(...)
+
+CODE:
+/*NOOP*/
+
#in case you need Apache::fork
# INCLUDE: fork.xs
Index: src/modules/perl/mod_perl.c
===
RCS file: /home/cvs/modperl/src/modules/perl/mod_perl.c,v
retrieving revision 1.126
diff -u -r1.126 mod_perl.c
--- src/modules/perl/mod_perl.c 2000/09/01 05:23:17 1.126
+++ src/modules/perl/mod_perl.c 2000/09/25 19:16:05
@@ -591,6 +591,13 @@
perl_startup(s, p);
}
+static void override_core_global(char *name)
+{
+GV *gv = gv_fetchpv(form("CORE::GLOBAL::%s", name), TRUE, SVt_PVCV);
+GvCV(gv) = perl_get_cv(form("Apache::%s", name), TRUE);
+GvIMPORTED_CV_on(gv);
+}
+
void perl_startup (server_rec *s, pool *p)
{
char *argv[] = { NULL, NULL, NULL, NULL, NULL, NULL, NULL };
@@ -771,10 +778,10 @@
#endif
/* *CORE::GLOBAL::exit = \Apache::exit */
-if(gv_stashpv("CORE::GLOBAL", FALSE)) {
- GV *exitgp = gv_fetchpv("CORE::GLOBAL::exit", TRUE, SVt_PVCV);
- GvCV(exitgp) = perl_get_cv("Apache::exit", TRUE);
- GvIMPORTED_CV_on(exitgp);
+/* *CORE::GLOBAL::srand = \Apache::srand */
+if (gv_stashpv("CORE::GLOBAL", FALSE)) {
+override_core_global("exit");
+override_core_global("srand");
}
if(PERL_STARTUP_DONE_CHECK){
@@ -941,6 +948,7 @@
register_cleanup(p, args, perl_child_exit_cleanup, null_cleanup);
mod_perl_init_ids();
+perl_eval_pv("CORE::srand()", TRUE);
Apache__ServerStarting(FALSE);
PERL_CALLBACK(hook, cls-PerlChildInitHandler);
}
Re: mod_perl guide corrections
On 14 Sep 2000, Joe Schaefer wrote: 2) Apache::Request is better than your performance numbers indicate. The problem I have with your comparison with Apache::args vs Apache::Request vs CGI is that your benchmark code isn't fair. You're comparing method calls against hash-table lookups, which is apples and oranges. To get more representative numbers, try the following code instead my $args = $q-param; # hash ref you mean parms() ? the Apache::Request::parms hash ref is tied, so there are still method calls, but less than calling params(), which does extra stuff to emulate CGI::params. parms() is going to be renamed (to something less like params()) and documented as faster than using the params() wrapper, in the next release.
Re: Value of ErrorLog directive via mod_perl
On 15 Sep 2000, Bjørn Ola Smievoll wrote: I need to retrieve the value of the ErrorLog directive (i.e. the path filename of the error_log), but I can't find a way to do it with mod_perl. (The C api equivalent is the error_fname field in the server_rec struct). this patch should work. can you tell me why you need it so i can decide if this should be added to the distribution? Index: src/modules/perl/Server.xs === RCS file: /home/cvs/modperl/src/modules/perl/Server.xs,v retrieving revision 1.6 diff -u -r1.6 Server.xs --- src/modules/perl/Server.xs 1999/08/20 08:34:43 1.6 +++ src/modules/perl/Server.xs 2000/09/25 20:12:57 @@ -135,6 +135,16 @@ # char *names;/* Wildcarded names for HostAlias servers */ # char *virthost; /* The name given in VirtualHost */ +char * +error_fname(server) +Apache::Server server + +CODE: +RETVAL = server-error_fname; + +OUTPUT: +RETVAL + int timeout(server, set=0) Apache::Server server
Re: usemymalloc mod_perl
On Sat, 16 Sep 2000, Ian Kallen wrote: I've seen some of the 'perl -V' outputs on this list over the years. Most people have usermymalloc=n but I've a seen a number of Solaris cases that have usemymalloc=y I have a system on Solaris 2.6 with usemymalloc=y and I have a very infrequent bug that usually manifests iteslef as corrupted data at the 64th byte (it can also happen at the 32nd byte!). It doesn't seem to happen ever in single process mode but I have some data objects that will consistently demonstrate this behavior with Apache forked (the bug survives apache shutdowns/startups, so it's not just an errant child). The other pieces of the puzzle: latest DBI, DBD::Oracle, Oracle 8.1.5 So, my question for this group: why would I want usemymalloc=y on Solaris 2.6? Besides having to rebuild a somewhat complex mod_perl compile, I'm not looking forward to rebuilding all libraries with XS code so any insight as to the ins and outs of compiling w/ and w/o usemymalloc would be much appreciated! thanks, solaris system malloc will degrade your Perl performance a great deal. i'd be surprised if the bug is caused by Perl's malloc implementation. sounds more like buggy xs (or linked in library code) that is stepping out of bounds, duplicate free() or similar. purify would be the best tool to find the bug, but rather expensive if you don't have it already. can you tell us more about this data, like what structure it is, where it's passed around in what code?
Re: dir_config and Apache::Table confusion
On 21 Sep 2000, Bjørn Ola Smievoll wrote:
If I do this:
$r-print($r-dir_config('key'));
Then key is printed.
If I then do this:
my $tab = $r-dir_config;
$r-print(Dumper($tab)); # Using Data::Dumper
I get '$VAR1 = bless( {}, 'Apache::Table' )';
It's empty, how come?
works fine for me with this config:
Location /perl
PerlSetVar foo bar
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
/Location
and test:
use Data::Dumper;
my $r = shift;
$r-send_http_header;
$r-print($r-dir_config('foo'), "\n");
my $tab = $r-dir_config;
$r-print(Dumper $tab);
outputs:
bar
$VAR1 = bless( {
'foo' = 'bar'
}, 'Apache::Table' );
with mod_perl-1.24_01-dev, apache_1.3.13-dev, perl-current (5.7.0@7093)
Re: open(FH,'|qmail-inject') fails
On Mon, 25 Sep 2000, Stas Bekman wrote: All you care about is to measure the time between email sending start and end (when the process continues on its execution flow). Why should one care about the details of internal implementation. i only skimmed the first part of this thread, but assumed if you're talking about performance, you'd want to compare the overall impact on your system(s) of Net::SMTP vs. |qmail-inject. you cannot measure the overall impact just using Benchmark.pm is all i'm trying to clarify.
Re: mod_perl IfModule directives?
On Tue, 12 Sep 2000, Matt Sergeant wrote: I know this isn't in mod_perl yet, so take this as a feature request :-) really, how do you know that? ;) What I'd like to see is a mod_perl equivalent of IfModule, so that I can add custom config directives to my httpd.conf perfectly safely: IfPerlModule AxKit AxAddStyleMap text/xsl Apache::AxKit::Language::Sablot /IfPerlModule you can already do that with modules that implement directive handlers: PerlModule Apache::AxKit IfModule Apache::AxKit ... /IfModule i didn't realize/thinkabout it until you asked though. p.s. have a look at mod_info's output w/ AxKit loaded if you haven't already
Re: modperl startup dumps core; trace included
On Mon, 11 Sep 2000, Bruce W. Hoylman wrote:
I have a peculiar problem with a modperl module I have written. When
migrating to the following configuration:
perl, v5.6.0 built for sun4-solaris
modperl_2911162240 (1.2401)
apache-1.3_2911161201
If I attempt to load the module in my startup.pl using:
use Savvy::Moveform ();
the server SIGSEGVs with the following stack trace:
looks like one of the 5.6.0 bugs, the Perl patch has been posted here
(don't have it handy), here's one that has also helped on the mod_perl
side, does it fix the problem for you?
--- perl_util.c~Tue Jun 13 10:25:38 2000
+++ perl_util.c Tue Jun 13 11:16:45 2000
@@ -547,12 +547,14 @@
{
dTHR;
SV *sv = sv_newmortal();
+COP *old_cop = curcop;
dTHRCTX;
sv_setpvn(sv, "require ", 8);
MP_TRACE_d(fprintf(stderr, "loading perl module '%s'...", name));
sv_catpv(sv, name);
perl_eval_sv(sv, G_DISCARD);
+curcop = old_cop;
if(s) {
if(perl_eval_ok(s) != OK) {
MP_TRACE_d(fprintf(stderr, "not ok\n"));
RE: Core dumping
On Sat, 9 Sep 2000, Shane Adams wrote:
#7 0x80894de in XS_Apache_finfo (cv=0x8207410) at Apache.xs:1844
i haven't tried to reproduce this, but suspect a bug in $r-finfo which
the patch below should workaround.
--- lib/HTML/Mason/ApacheHandler.pm~Thu Aug 24 22:42:51 2000
+++ lib/HTML/Mason/ApacheHandler.pm Mon Sep 11 11:43:02 2000
@@ -531,7 +531,7 @@
# If filename is a directory, then either decline or simply reset
# the content type, depending on the value of decline_dirs.
#
-if (-d $r-finfo) {
+if (-d $r-filename) {
if ($self-decline_dirs) {
return DECLINED;
} else {
@@ -544,7 +544,7 @@
# (mainly for dhandlers).
#
my $pathname = $r-filename;
-$pathname .= $r-path_info unless -f $r-finfo;
+$pathname .= $r-path_info unless -f _;
#
# Compute the component path via the resolver.
@@ -555,7 +555,7 @@
#
# Decline if file does not pass top level predicate.
#
-if (-f $r-finfo and defined($self-{top_level_predicate})) {
+if (-f _ and defined($self-{top_level_predicate})) {
return NOT_FOUND unless $self-{top_level_predicate}-($r-filename);
}
Re: Memory leak hell...
On Sun, 10 Sep 2000, Matt Sergeant wrote:
For 2 days solid now I've been trying to track down a very bizarre memory
leak in AxKit.
I've checked everything I can think of - all circular references are now
gone, all closures clean up carefully after themselves, and I've reduced
the usage of some external modules. But still the processes grow.
Now to the wierd bit. I could track this down if it wasn't for this:
The memory leak starts after the Nth hit, usually around 35. This is
running under httpd -X.
So it goes along very happily for 35 hits - memory usage is rock solid
stable. Then after the 35th hit the memory usage starts to grow about 4k
per hit. Obviously thats an impossible rate of growth to sustain for any
amount of time, and soon the server is swamped.
you're leaking on every request, consider this example:
use strict;
my $i = 0;
my @a;
my $old_size = proc_size();
while (++$i) {
my $size = proc_size();
if ($size != $old_size) {
printf "Size changed from $old_size to $size, i=$i\n";
$old_size = $size;
; #pause
}
push @a, [];
}
sub proc_size {
my $size = 0;
open my $fh, "/proc/self/status";
while ($fh) {
last if (($size) = (/^VmRSS:\s+(\d+)/));
}
close $fh;
$size;
}
outputs:
Size changed from 1376 to 1436, i=1
Size changed from 1436 to 1472, i=2
Size changed from 1472 to 1476, i=55
Size changed from 1476 to 1480, i=99
Size changed from 1480 to 1484, i=158
Size changed from 1484 to 1488, i=204
Time::HiRes, Apache::* (core apache stuff only), AxKit, Digest::MD5,
Compress::Zlib, Fcntl, XML::Parser, XML::XPath, Unicode::Map8,
Unicode::String, MIME::Base64, Storable (loaded but not used),
XML::Sablotron (loaded but not used).
look for xsubs in those modules you're using that are calling
new{SV,AV,HV,RV} or SvREFCNT_inc(). sounds like botched refcnting or
failure to mortalize a new*V.
actually, my first guess is Apache::ModuleConfig-get, if you don't
explicitly pass __PACKAGE__ as the last argument, perl_eval_pv() is
called, which has a leak plugged in perl-current:
[ 6201] By: gsar on 2000/06/06 00:42:59
Log: Perl_eval_pv() leaks 4 bytes every time it is called because it
does a PUSHMARK that's never ever POPMARKed; in general, only
Perl_call_[sp]v() need a PUSHMARK for incoming arguments;
Perl_eval_[sp]v() don't because they don't take any incoming
arguments (this leak has been around since the original version
of perl_eval_pv() in 5.003_97e)
Branch: perl
! perl.c
so first try changing:
Apache::ModuleConfig-get($r)
to
Apache::ModuleConfig-get($r, __PACKAGE__)
Re: PerlCleanupHandler
On Fri, 11 Aug 2000, Tim Sweetman wrote: I've seen something similar - when the client browser times out, execution seems to stop mid-Print statement, and mod_Perl gets ready for the next request, without cleaning up objects present (or, at least, without calling -DESTROY). this should be fixed with the hard_timeout - soft_timeout change. IIRC, "END" blocks are called by mod_Perl, rather than Perl itself, since Perl normally calls them only when the interpreter is about to shut down. END blocks still get called in this situation, so if you run foo.pl and manage to hit stop before it's printed its output... right, because mod_perl runs Apache::Registry END blocks in a cleanup. More disturbingly, there seem to be very occasional cases where the cleanup stuff doesn't do what's expected of it, so I suggest you keep an eye on what's happening. Our current workaround - not a good one - is to kill $$ when objects don't get cleaned up correctly. hmm, the hard_timeout() may have left Perl in a confused state. if you're still seeing this behavior with the soft_timeout() change, i'd appreciate any details you have on this.
Re: $r-notes with slashes
On Mon, 14 Aug 2000, Andrew Fuqua wrote:
I'm trying to pass a path name with slashes as the value of a note, and
when I try to retrieve the note from another handler in the same
request, the note is not there. Code goes like this:
in a PerlInitHandler:
$r-notes('dir_name' = '/some/dir/name/');
later, in a PerlAuthzHandler:
my $dir_name = $r-notes('dir_name');
and $dir_name is empty. :( I can set and retrieve the note just fine
as long as there are no slashes in the note.
works fine for me with this test case:
Location /
PerlInitHandler 'sub { shift-notes(dir_name = "/some/dir/name/") }'
require valid-user
AuthType basic
AuthName test
PerlAuthenHandler Apache::OK
PerlAuthzHandler 'sub { Apache::OK if shift-notes("dir_name") }'
/Location
you'll only get prompted for user/pass if dir_name is not found in the
notes table, does it work for you?
Another question. From a handler, how can I change the value of a
variable that was PerlSetVar'ed in httpd.conf?
as geoff explained, you can, but the value might stick for that child if
the SetVar was configured in httpd.conf. so you might want to reset it:
my $old_val = $r-dir_config-get('foo');
$r-register_cleanup(sub { shift-dir_config-set(foo = $old_val) });
$r-dir_config-set(foo = $new_val);
Re: [ID 20000818.003] mod_perl Apache::Symbol::undef() is deprecated
On Wed, 30 Aug 2000, Brian S. Craigie wrote: [Thu Aug 17 20:23:37 2000] [error] Can't locate auto/Apache/Symbol/undef.al in @INC (@INC contains: ... /usr/local/lib/perl5/sun4-solaris/5.00404 /usr/local/lib/perl5 to upgrade to perl 5.6.0 you upgraded to 5.6.0 but mod_perl is still looking in 5.00404's @INC. try starting over with freshly unpacked source trees and make sure that the 5.6.0 perl is first in your PATH (or whichever user is building mod_perl)
Re: Apache.xs patch for get_client_block
On 31 Aug 2000 [EMAIL PROTECTED] wrote:
The mod_perl implementation of get_client_block has a memory leak.
The following patch should keep it from from pissing in r-pool.
thanks joe. i don't see how allocating from r-pool is a "leak", but
yeah, it is a waste of resources since Perl is going to make it's own
copy. read_client_block() has similar waste which i've been meaning to
fix. this patch trims allocations for both by reading directly into
Perl's buffer:
Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.106
diff -u -r1.106 Apache.xs
--- src/modules/perl/Apache.xs 2000/08/31 05:49:06 1.106
+++ src/modules/perl/Apache.xs 2000/08/31 20:33:03
@@ -940,7 +940,7 @@
void
read_client_block(r, buffer, bufsiz)
Apache r
-char*buffer
+SV*buffer
int bufsiz
PREINIT:
@@ -948,29 +948,31 @@
int rc;
PPCODE:
-buffer = (char*)safemalloc(bufsiz);
if ((rc = setup_client_block(r, REQUEST_CHUNKED_ERROR)) != OK) {
aplog_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO, r-server,
"mod_perl: setup_client_block failed: %d", rc);
XSRETURN_UNDEF;
}
-if(should_client_block(r)) {
- nrd = get_client_block(r, buffer, bufsiz);
- r-read_length = 0;
+if (should_client_block(r)) {
+SvUPGRADE(buffer, SVt_PV);
+SvGROW(buffer, bufsiz+1);
+nrd = get_client_block(r, SvPVX(buffer), bufsiz);
+r-read_length = 0;
}
if (nrd 0) {
- XPUSHs(sv_2mortal(newSViv((long)nrd)));
- sv_setpvn((SV*)ST(1), buffer, nrd);
+XPUSHs(sv_2mortal(newSViv((long)nrd)));
#ifdef PERL_STASH_POST_DATA
-table_set(r-subprocess_env, "POST_DATA", buffer);
+table_set(r-subprocess_env, "POST_DATA", SvPVX(buffer));
#endif
-safefree(buffer);
- SvTAINTED_on((SV*)ST(1));
+SvCUR_set(buffer, nrd);
+*SvEND(buffer) = '\0';
+SvPOK_on(buffer);
+SvTAINTED_on(buffer);
}
else {
- ST(1) = sv_undef;
+sv_setsv(buffer, sv_undef);
}
int
@@ -985,22 +987,25 @@
void
get_client_block(r, buffer, bufsiz)
Apache r
-char*buffer
+SV*buffer
int bufsiz
PREINIT:
long nrd = 0;
PPCODE:
-buffer = (char*)palloc(r-pool, bufsiz);
-nrd = get_client_block(r, buffer, bufsiz);
+SvUPGRADE(buffer, SVt_PV);
+SvGROW(buffer, bufsiz+1);
+nrd = get_client_block(r, SvPVX(buffer), bufsiz);
if ( nrd 0 ) {
XPUSHs(sv_2mortal(newSViv((long)nrd)));
- sv_setpvn((SV*)ST(1), buffer, nrd);
- SvTAINTED_on((SV*)ST(1));
+SvCUR_set(buffer, nrd);
+*SvEND(buffer) = '\0';
+SvPOK_on(buffer);
+SvTAINTED_on(buffer);
}
else {
- ST(1) = sv_undef;
+ sv_setsv(ST(1), sv_undef);
}
int
Re: Apache.xs patch for get_client_block
On 31 Aug 2000 [EMAIL PROTECTED] wrote:
Doug,
Sorry to belabor a dull issue, but I'm not sure I'm getting my point across.
no problem, this is important stuff to understand.
Most of the troubles I've run across in the mod_perl and libapreq code
have to do with attempts to allocate memory resources for buffers
at runtime. That's exactly what the BUFF API does, right?
not really, BUFF uses some stack allocation, it's generally up to the
caller to manage i/o buffers.
What I'm seeing is that you are also resizing/reallocating these buffers
each time the code is called. For instance, the original
get_client_block had this line in it:
-buffer = (char*)palloc(r-pool, bufsiz);
The one you just sent me has this line instead:
+SvGROW(buffer, bufsiz+1);
I'm not sure what SvGROW does, but if it involves a malloc
without freeing the old buffer, you've got the same problem as before.
Each time the perl version of get_client_block is called,
SvGROW will work it's majic on RAM, and perl won't give that RAM
back to the OS.
but that "problem" still existed with your patch in this line:
sv_setpvn((SV*)ST(1), buffer, nrd);
same thing happens underneath (see sv.c). we can't just point Perl
variables at buffers allocated on the stack. SvGROW() will only malloc()
(or realloc) if the buffer isn't already large enough to the given length.
Perl hangs onto that allocation as an optimization, so it only has to
malloc() once for a given variable, and maybe realloc() if a later string
assignment is larger. consider this example:
sub foo {
...
my $buff;
while (my $len = $r-get_client_block($buff, 1024)) {
print "$buff\n";
}
...
}
the SvGROW() underneath will only trigger malloc() for $buff _once_, for
the entire lifetime of the process.
Perl will only release the string buffer allocation if you explicity
undef() the variable. this is true for all variables, including those
scoped with my(). clearly, you would not want to undef($buff) inside the
while loop, otherwise malloc() will be called each time through the loop.
outside the loop would not be so bad, then malloc() will only happen for
$buff each time sub foo is called. if it's called often, like for every
request, it might be better to let Perl hang onto the allocation, that's
up to you.
now, what happens when that buffer is released depends on your Perl and
perhaps os. if your Perl is built with Perl's malloc, the free()
triggered by undef() will give the memory back to Perl's pool of memory.
otherwise, free() will probably resolve to libc's free(). on some
platforms that means it is "given back to the os", on others it just means
that chunk of memory is available for reuse in that process the next time
somebody malloc's.
Re: mod_perl for Apache to work with ActivePerl (APR#816)
On Fri, 25 Aug 2000, Gurusamy Sarathy wrote: mod_perl apparently doesn't know anything about ithreads. This patch makes it build and "work" for me, but I haven't tested it for more than 20 seconds. It is possible that similar treatment is needed for other callbacks that my 20-seconds worth of testing did not trigger. :-) strange, my Perl is an ithreads Perl, has been for several months. i had to make several changes initially, but it's been running for me with linux+ithreads since. anyhow, still runs fine with your patch (committed to cvs for 1.25) and Randy Kobes has confirmed the win32 side. thanks Sarathy!!
Re: Build problems on Solaris
On Thu, 10 Aug 2000, Paul Breslaw wrote: I cannot get mod_perl to pass 'make test' on Solaris (5.5.1). I've tried different versions of mod_perl (1.18, 1.21_03 and 1.24) and different versions of Apache (1.3.4, 1.3.12) all against the same version of perl 5.004_04 (gcc). I used the INSTALL.simple build, most of the time, but also examples from INSTALL.apaci, eg perl Makefile.PL EVERYTHING=1 APACHE_HEADER_INSTALL=0 PERL_TRACE=1 Whatever combination I use, I get output something like that listed below. Bad free() ignored at /usr/local/lib/perl5/Exporter.pm line 232. if you haven't tried already, a newer version of Perl might help, a number of Perl malloc() bugs have been fixed since 5.004_04
Re: Apache::Registry spawning zombie shells?
On Tue, 22 Aug 2000, martin langhoff wrote:
hi list,
while doing a silly thing (building a set of HTML files with info from
a DB file), I found that while the apache server was being crawled by
lwp-rget, a lots of zombie shells were being spawned and killed.
sh -c /bin/csh -cf 'set nonomatch; glob /table' 2/de
it looks like one of your html tags is astray, which Perl interprets as
a glob, e.g.
% strace -o strace.out -f /usr/bin/perl -e '/table'
% grep glob strace.out
10627 execve("/bin/csh", ["/bin/csh", "-cf", "set nonomatch; glob /table"], [/* 56
vars */]) = 0
i don't see any in your script that would trigger that, but you might want
to double check where all of your /table tags are.
Re: 'make test' error with CVS modperl
On Tue, 22 Aug 2000, Bruce W. Hoylman wrote: Having downloaded the latest CVS snapshot of modperl, using my standard APACI config parameters to configure and compile, it compiles to completion without error. 'make test' however returns the following error when attempting to start the test httpd process: letting apache warm up...[Tue Aug 22 10:46:31 2000] [error] Can't load '/opt/gnu/lib/perl5/5.00503/sun4-solaris/auto/IO/IO.so' for module IO: ld.so.1: /www/src/apache-1.3_2817161200/src/httpd: fatal: relocation error: file /opt/gnu/lib/perl5/5.00503/sun4-solaris/auto/IO/IO.so: symbol main: referenced symbol not found at /opt/gnu/lib/perl5/5.00503/sun4-solaris/DynaLoader.pm line 169. I have IO-1.20 installed, and have had it there for a long time. Here are the particulars for perl: so if you 'make test' with the same Perl and 1.24 you don't have this problem? i don't see any changes since that could trigger such a problem.
RE: env in background process
On Wed, 23 Aug 2000, Sheth, Niraj wrote: Didn't get any reply yet on this, so I think i am doing something very stupid ... i'm still catching up with plenty of unanswered mail in my modperl mailbox, including yours, doing the best i can.
Re: Apache::Config
On Thu, 24 Aug 2000, Stas Bekman wrote: Is it just me or has there been discussionof something along the lines of Apache::Config here before? Where might I accquire it? I could not find it on CPAN... It will appear in mod_perl-2.0 for sure, and it's on the todo list of mod_perl-1.x, so if you come up with a patch that implements this module for 1.x everybody will be very grateful to you or whoever conributes it. Otherwise you'll have to wait before someone will implement it. i don't think he's looking for Apache::BuildConfig, but the Apache::Config httpd.conf parser Jerrad Pierce is working on.
Re: Patch to t/modules/request.t
this thread is pretty large, i'm sure the fix is nice and small, anybody have a patch with the final solution? thanks.
Re: PerlCleanupHandler
On Wed, 9 Aug 2000, Michael Peppler wrote:
Hi,
We're seeing a number of requests where the write from apache to the
client browser times out and the SIGALRM signal fires. Our
Apache::Registry scripts in that case don't clean up correctly,
leaving session lock files around, which of course causes that
particular session to be screwed up for a while.
My question is would a Cleanup handler still be called in this case?
yes. but, the proper solution is for mod_perl to change usage of
hard_timeout() to soft_timeout(). hard_timeout() does a longjmp out to
the accept loop, whereas soft_timeout() just sets $r-connection-aborted
to 1, so all apache i/o calls become noops, but the script continues to
run until finished. i don't know why we used hard_timeout() in the first
place. if a script wants to abort, they'll need to do it themselves,
something along the lines of:
$r-print('foo');
die if $r-connection-aborted;
Index: Apache/Apache.pm
===
RCS file: /home/cvs/modperl/Apache/Apache.pm,v
retrieving revision 1.52
diff -u -r1.52 Apache.pm
--- Apache/Apache.pm2000/08/15 04:35:13 1.52
+++ Apache/Apache.pm2000/08/31 05:38:36
@@ -68,7 +68,7 @@
$_[1] ||= "";
#$_[1] = " " x $bufsiz unless defined $_[1]; #XXX?
-$r-hard_timeout("Apache-read");
+$r-soft_timeout("Apache-read");
while($bufsiz) {
$nrd = $r-read_client_block($buf, $bufsiz) || 0;
@@ -113,7 +113,7 @@
return 0;
}
-$r-hard_timeout("Apache-read");
+$r-soft_timeout("Apache-read");
while($bufsiz) {
$nrd = $r-get_client_block($buf, $bufsiz) || 0;
@@ -425,7 +425,7 @@
looping until it gets all of C$bytes_to_read or a timeout happens.
In addition, this method sets a timeout before reading with
-C$r-Egthard_timeout.
+C$r-Egtsoft_timeout.
=item $r-get_remote_host
@@ -909,7 +909,7 @@
=item $r-print( @list )
This method sends data to the client with C$r-Egtwrite_client, but first
-sets a timeout before sending with C$r-Egthard_timeout. This method is
+sets a timeout before sending with C$r-Egtsoft_timeout. This method is
called instead of CORE::print when you use print() in your mod_perl programs.
This method treats scalar references specially. If an item in @list is a
Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.105
diff -u -r1.105 Apache.xs
--- src/modules/perl/Apache.xs 2000/08/31 03:39:45 1.105
+++ src/modules/perl/Apache.xs 2000/08/31 05:38:48
@@ -1033,7 +1033,7 @@
}
else {
CV *cv = GvCV(gv_fetchpv("Apache::write_client", FALSE, SVt_PVCV));
- hard_timeout("mod_perl: Apache-print", r);
+ soft_timeout("mod_perl: Apache-print", r);
PUSHMARK(mark);
#ifdef PERL_OBJECT
(void)(*CvXSUB(cv))(cv, pPerl); /* Apache::write_client; */
Re: Patch to t/modules/request.t
On Thu, 31 Aug 2000, Ken Williams wrote: [EMAIL PROTECTED] (Doug MacEachern) wrote: this thread is pretty large, i'm sure the fix is nice and small, anybody have a patch with the final solution? thanks. Sounds so ominous... =) didn't mean it to, i'm just buried and looking for any shortcuts out, thanks :)
Apache::Icon fix
with the patch below, Apache::Icon/Apache::AutoIndex works fine for me. running apache_1.3.13-dev, mod_perl-1.24_01-dev, perl-current (5.7.0-dev) mod_perl built with EVERYTHING=1, USE_DSO=1 copy-n-pasted config from Apache::AutoIndex/README: PerlModule Apache::Icon PerlModule Apache::AutoIndex PerlTransHandler Apache::AutoIndex::transhandler PerlHandler Apache::AutoIndex kill -HUP works just fine too. --- Icon.xs 1999/01/18 19:21:46 1.1.1.1 +++ Icon.xs 2000/08/21 16:50:04 @@ -18,6 +18,12 @@ PROTOTYPES: DISABLE +void +END() + +CODE: +ap_remove_module(icon_module); + Apache::Icon new(class, r=default_r) char *class
Re: cgis and subrequests
On Sun, 20 Aug 2000, Alex Menendez wrote: unfortunately, I am not entirely sure what a cgi is going to output all the time. The cgi might try to do a redirect using the Location field. Therefore, I don't think I can simply send_http_headers as type text/html... right, my $lookup = $r-lookup_uri( $uri ); $r-send_http_header( 'text/html' ); so just change that line to: $lookup-send_http_header; and you'll get the content-type and headers generated by the subrequest. if there's a bug, it's in the book, subrequest-run() is not supposed to include headers in the output.
Re: send_http_header and subrequests
On Wed, 14 Jun 2000, Paul J. Lucas wrote:
The second example on p. 128 of the Eagle book sets the content
type and send the HTTP headers itself before running a
subrequest.
However, on p. 468, the documentation for the run() method says
in part:
When you invoke the subrequest's response handler in
this way, it will do everything a response handler is
supposed to, includinf sendinf the HTTP headers and the
document body. ... If you arevoking the subrequest
urn() method from within your own content handler, you
must not sen the HTTP headers and document body
yourself ...
These seem to contradict each other. From testing, however, it
seems as though the example on p. 128 is correct and the
documentation on p. 468 isn't. Is this true?
right, subrequest-run does not output headers.
my $sub_r = $r-lookup_file( $full_path );
my $status = $sub_r-status();
unless ( $status == DOCUMENT_FOLLOWS ) {
$r-log_error( "Can't look up $full_path" );
return $status;
}
$r-send_http_header( $sub_r-content_type() );
does it help if you change that to:
$sub_r-send_http_header;
?
Re: httpd.conf directive PerlHandler Apache::Hello-handler errors
On Thu, 10 Aug 2000, Ken Williams wrote:
To clarify - some handlers can be called using object-oriented
techniques, and some can't. The switch for this behavior is that the
handler is prototyped with ($$).
or with newer Perls:
sub handler : method {...}
Re: Cant set args to $r-arg(undef);
On Sun, 13 Aug 2000, Greg Cope wrote: Dear All Although this in no longer important to me, I cannot appear to reset $r-arg to an empty value. i think i already mentioned (but this message is not marked as replied), this is fixed in cvs.
Re: my transhandler runs only once in each child ?!?
On Mon, 14 Aug 2000, Matt Sergeant wrote:
On Sun, 13 Aug 2000, Greg Cope wrote:
Apache-push_handlers("PerlTransHandler", \transhandler);
push_handlers is temporary, not permanent. And this line only gets
executed once.
of course, if you wanted something like that, your module (if loaded at
startup) can do this:
{
package Apache::ReadConfig;
push @PerlTransHandler, join '::', __PACKAGE__, 'transhandler';
}
Re: Errors from Apache.pm
On Wed, 16 Aug 2000 [EMAIL PROTECTED] wrote: All, I am seeing the following errors in my apache error log. These have appeared since moving to a Linux/mod_perl1.24 combination (from NT/1.23) so I don't know if they come from 1.24 or from the -w switch being handled better under unix. Anyone know what these are and how to get rid of them ? I had a look but I really don't feel confident enough do start playing around with this module :-) [Wed Aug 16 17:45:12 2000] null: Use of uninitialized value at /usr/lib/perl5/site_perl/5.005/i386-linux/Apache.pm line 184. [Wed Aug 16 17:45:12 2000] null: Use of uninitialized value at /usr/lib/perl5/site_perl/5.005/i386-linux/Apache.pm line 184. [Wed Aug 16 17:45:13 2000] null: Use of uninitialized value at /usr/lib/perl5/site_perl/5.005/i386-linux/Apache.pm line 184. that line is in send_cgi_header(), which means you've configured PerlSendHeader On. how is your code sending headers? looks like something that send_cgi_header() can't parse.
Re: mod_perl-1.24 - Make FAILS!
On Thu, 17 Aug 2000, Stephen Marriott wrote: /usr/lib/perl5/5.00503/i386-linux/CORE/perl.h:2546: redefinition of `union semun' Perl version 5.005_03 built for i386-linux (2.0.36) this problem has been reported in the past, upgrading to a newer kernel has cured.
Re: Anyone get Apache::PerlVINC to work?
On Sat, 19 Aug 2000, Stas Bekman wrote: On Fri, 18 Aug 2000, Tom Lancaster wrote: I get the behaviour described in the BUGS section of the docs: server silently fails to start. However, I'm using the latest version of Apache::ExtUtils, as recommended. Also using mod_perl 1.22, Apache 1.3.12, Apache::ASP 2.03. Has anyone got PerlVINC to work with this combo? Use the latest version, it's not a part of the Apache::ExtUtils, but distributed in a separate package: the suggestion was to upgrade Apache::ExtUtils (to cvs version, w/ bug fix), which generates PerlVINC.xs.
Re: cgis and subrequests
whoops. yeah, $subr-send_http_header won't work for the same reason send_http_header() calls within run() do not. you'll just need to propagate subrequest info like so: my $subr = $r-lookup_uri($uri); $r-send_http_header($subr-content_type); $subr-run;
Re: Anyone get Apache::PerlVINC to work?
On Mon, 21 Aug 2000, Tom Lancaster wrote: Doug MacEachern wrote: the suggestion was to upgrade Apache::ExtUtils (to cvs version, w/ bug fix), which generates PerlVINC.xs. Where can I find this? % perldoc mod_perl_cvs
Re: cgis and subrequests
On Mon, 21 Aug 2000, Alex Menendez wrote:
ok, what about cgi's that generate Location: headers. Am I out of luck
here? should I contemplate changing src for ap_run_sub_req
doh, right, headers are not added until run(). no need to change
ap_run_sub_req, we can support this. with the patch below you can say
$subr-run(1), where 1 enables send_http_header() within subrequests.
--- src/modules/perl/Apache.xs 2000/08/15 19:36:32 1.103
+++ src/modules/perl/Apache.xs 2000/08/21 19:38:32
@@ -1996,10 +2003,15 @@
"Apache::SubRequest::DESTROY(0x%lx)\n", (unsigned long)r));
int
-run(r)
+run(r, allow_send_header=0)
Apache::SubRequest r
+int allow_send_header
CODE:
+if (allow_send_header) {
+r-assbackwards = 0;
+}
+
RETVAL = run_sub_req(r);
OUTPUT:
RE: $r-get_handlers bug/oversight?
On Wed, 16 Aug 2000, Geoffrey Young wrote:
ack... so the alias only goes one way? I guess it makes sense that we
can't know at run time what the Init handler stands for, but how come
get_handlers('PerlInitHandler') comes up blank? Isn't it just a table
entry?
it's not in the get/set handler lookup table. just use
PostReadRequest/HeaderParser for now, we'll see about making Init do the
right thing with get/set handlers later.
well, it got the handler ok, but I couldn't set it properly:
#!/usr/bin/perl
my $r = shift;
$r-set_handlers(PerlCleanupHandler = [\cleanup]);
$r-send_http_header('text/plain');
print "done";
sub cleanup {
warn "hi";
}
is a no go. same with using ['My::Cleanup'] as the arg...
ok, fixed, problem described in new Apache.xs comment:
/* since register_cleanups are fifo, and the already registered
* mod_perl_end_cleanup() runs PerlCleanupHandlers, PerlCleanupHandler
* needs to maintain the refcnt itself
*/
I also noticed that the patch didn't fix the get_handlers() coderef bug:
#!/usr/bin/perl
my $r = shift;
$r-push_handlers(PerlCleanupHandler = sub { warn "hi"; });
#my $handlers = $r-get_handlers('PerlCleanupHandler');
$r-send_http_header('text/plain');
print "done";
uncomment the get_handlers() line and the cleanup handler never runs and you
get "Attempt to free unreferenced scalar"
i see the problem, perl_handler_merge_avs() did not increment the
reference counts during av_push(). below is the current patch against cvs
which fixes both problems. thanks for testing geoff!
Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.103
diff -u -r1.103 Apache.xs
--- src/modules/perl/Apache.xs 2000/08/15 19:36:32 1.103
+++ src/modules/perl/Apache.xs 2000/08/21 22:33:32
@@ -73,12 +73,6 @@
void (*set_func) (void *, void *, SV *);
} perl_handler_table;
-typedef struct {
-I32 fill;
-AV *av;
-AV **ptr;
-} perl_save_av;
-
static void set_handler_dir (perl_handler_table *tab, request_rec *r, SV *sv);
static void set_handler_srv (perl_handler_table *tab, request_rec *r, SV *sv);
@@ -101,77 +95,78 @@
{HandlerDirEntry("PerlFixupHandler", PerlFixupHandler)},
{HandlerDirEntry("PerlHandler", PerlHandler)},
{HandlerDirEntry("PerlLogHandler", PerlLogHandler)},
+{HandlerDirEntry("PerlCleanupHandler", PerlCleanupHandler)},
{ FALSE, NULL }
};
-static void perl_restore_av(void *data)
-{
-perl_save_av *save_av = (perl_save_av *)data;
-
-if(save_av-fill != DONE) {
- AvFILLp(*save_av-ptr) = save_av-fill;
-}
-else if(save_av-av != Nullav) {
- *save_av-ptr = save_av-av;
-}
-}
-
static void perl_handler_merge_avs(char *hook, AV **dest)
{
int i = 0;
HV *hv = perl_get_hv("Apache::PerlStackedHandlers", FALSE);
SV **svp = hv_fetch(hv, hook, strlen(hook), FALSE);
AV *base;
-
+
if(!(svp SvROK(*svp)))
return;
base = (AV*)SvRV(*svp);
for(i=0; i=AvFILL(base); i++) {
SV *sv = *av_fetch(base, i, FALSE);
- av_push(*dest, sv);
+ av_push(*dest, SvREFCNT_inc(sv));
}
}
+#define avptr_from_offset(ptr, tab) \
+(AV **)((char *)ptr + (int)(long)tab-offset)
+
static void set_handler_base(void *ptr, perl_handler_table *tab, pool *p, SV *sv)
{
-AV **av = (AV **)((char *)ptr + (int)(long)tab-offset);
+int do_register_cleanup = 0;
+AV **av = avptr_from_offset(ptr, tab);
-perl_save_av *save_av =
- (perl_save_av *)palloc(p, sizeof(perl_save_av));
-
-save_av-fill = DONE;
-save_av-av = Nullav;
-
-if((sv == sv_undef) || (SvIOK(sv) SvIV(sv) == DONE)) {
- if(AvTRUE(*av)) {
- save_av-fill = AvFILL(*av);
- AvFILLp(*av) = -1;
- }
-}
-else if(SvROK(sv) SvTYPE(SvRV(sv)) == SVt_PVAV) {
- if(AvTRUE(*av))
- save_av-av = av_copy_array(*av);
- *av = (AV*)SvRV(sv);
- ++SvREFCNT(*av);
+if ((sv == sv_undef) || (SvIOK(sv) SvIV(sv) == DONE)) {
+if (!*av) {
+do_register_cleanup = 1;
+}
+if (*av SvREFCNT(*av)) {
+SvREFCNT_dec(*av);
+}
+*av = newAV();
+}
+else if (SvROK(sv) SvTYPE(SvRV(sv)) == SVt_PVAV) {
+*av = (AV*)SvRV(sv);
+++SvREFCNT(*av);
+do_register_cleanup = 1;
}
else {
- croak("Can't set_handler with that value");
+croak("Can't set_handler with that value");
+}
+
+/* since register_cleanups are fifo, and the already registered
+ * mod_perl_end_cleanup() runs PerlCleanupHandlers, PerlCleanupHandler
+ * needs to maintain the refcnt itself
+ */
+if (do_register_cleanup strNE(tab-name, "PerlCleanupHandler")) {
+register_cleanup(p, (void*)*av, mod_perl_cleanup_av, mod_perl_noop);
}
-save_av-ptr = av;
-register_cleanup(p,
Re: cvs snapshots
On Thu, 17 Aug 2000, Eric Cholet wrote: We no longer have cvs snapshots in http://dev.apache.org/from-cvs/ There's only httpd in there. (we link to this from http://perl.apache.org/distributions.html) i guess we should change it to: http://perl.apache.org/from-cvs/
Re: Seg fault (11) backtrace (long email) - was RE: does anyone havea fix for this?
On Thu, 3 Aug 2000, Jamie Krasnoo wrote:
Program received signal SIGSEGV, Segmentation fault.
0x8086ef0 in perl_handler_ismethod ()
yes, cvs should fix this, here's the diff:
--- mod_perl.c 2000/05/25 18:06:23 1.121
+++ mod_perl.c 2000/06/02 17:23:07 1.122
@@ -1222,7 +1222,7 @@
}
#ifdef CVf_METHOD
-if (CvFLAGS(cv) CVf_METHOD) {
+if (cv (CvFLAGS(cv) CVf_METHOD)) {
is_method = 1;
}
#endif
Re: [OT]SegFaults, not PerlFreshRestart or module related
On Mon, 19 Jun 2000, Paul wrote: I'm running out of ideas. PerlFreshRestart was completely unused, then explicitly set Off. I have two handlers, which seem to work well. My logs report nothing amiss aside from the stream of segmentation faults killing off my server children, usually several in quick succession, then minutes or hours apart. This makes me think it's usage-based (duh), but I can't seem to pin it down. And there are no core files. Shouldn't a segmentation fault that kills a process produce a core file? What gives? I even logged in as root and did a "find / -name 'core'", in case it was dumping it in some obscure spot off the normal web directories. Not a single hit. We don't have gdb on this server, but I assumed it was GNUware and was going to install it -- but doesn't it need a core file? I hate to even post this, but I'm completely baffled. I have users trying to hit the site from bookmarks, and getting the "document contained no data" popup; I can only assume it's my children segfaulting, and on no particular page. core files might not be produced depending on the user your server runs as, i think ulimit can change that or something, but don't know off the top of my head. if you can't reproduce the problem at will, attach to a any apache child (make sure it's not the parent!) with gdb (see the SUPPORT doc for hints) and wait for a segv. then pass along `bt' and `curinfo' to us.
Re: Yet more on set_handlers() and new-found problems with lookup_uri()
i think the jist of the problem(s), is that set_handlers() modifies the
configuration structure (the one created at startup from httpd.conf), so
any subrequests will end up with the modified structure (which is not
reset until the end of the request). this patch implements
{get,set}_handlers in terms of r-per_request_config, which is
unique to each (sub-)request. if this doesn't fix the problem, it would
really help to have a small test case that i can drop in to see the bug in
action.
Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.103
diff -u -r1.103 Apache.xs
--- src/modules/perl/Apache.xs 2000/08/15 19:36:32 1.103
+++ src/modules/perl/Apache.xs 2000/08/16 00:46:44
@@ -73,12 +73,6 @@
void (*set_func) (void *, void *, SV *);
} perl_handler_table;
-typedef struct {
-I32 fill;
-AV *av;
-AV **ptr;
-} perl_save_av;
-
static void set_handler_dir (perl_handler_table *tab, request_rec *r, SV *sv);
static void set_handler_srv (perl_handler_table *tab, request_rec *r, SV *sv);
@@ -101,28 +95,17 @@
{HandlerDirEntry("PerlFixupHandler", PerlFixupHandler)},
{HandlerDirEntry("PerlHandler", PerlHandler)},
{HandlerDirEntry("PerlLogHandler", PerlLogHandler)},
+{HandlerDirEntry("PerlCleanupHandler", PerlCleanupHandler)},
{ FALSE, NULL }
};
-static void perl_restore_av(void *data)
-{
-perl_save_av *save_av = (perl_save_av *)data;
-
-if(save_av-fill != DONE) {
- AvFILLp(*save_av-ptr) = save_av-fill;
-}
-else if(save_av-av != Nullav) {
- *save_av-ptr = save_av-av;
-}
-}
-
static void perl_handler_merge_avs(char *hook, AV **dest)
{
int i = 0;
HV *hv = perl_get_hv("Apache::PerlStackedHandlers", FALSE);
SV **svp = hv_fetch(hv, hook, strlen(hook), FALSE);
AV *base;
-
+
if(!(svp SvROK(*svp)))
return;
@@ -133,45 +116,53 @@
}
}
+#define avptr_from_offset(ptr, tab) \
+(AV **)((char *)ptr + (int)(long)tab-offset)
+
static void set_handler_base(void *ptr, perl_handler_table *tab, pool *p, SV *sv)
{
-AV **av = (AV **)((char *)ptr + (int)(long)tab-offset);
+int do_register_cleanup = 0;
+AV **av = avptr_from_offset(ptr, tab);
-perl_save_av *save_av =
- (perl_save_av *)palloc(p, sizeof(perl_save_av));
-
-save_av-fill = DONE;
-save_av-av = Nullav;
-
-if((sv == sv_undef) || (SvIOK(sv) SvIV(sv) == DONE)) {
- if(AvTRUE(*av)) {
- save_av-fill = AvFILL(*av);
- AvFILLp(*av) = -1;
- }
-}
-else if(SvROK(sv) SvTYPE(SvRV(sv)) == SVt_PVAV) {
- if(AvTRUE(*av))
- save_av-av = av_copy_array(*av);
- *av = (AV*)SvRV(sv);
- ++SvREFCNT(*av);
+if ((sv == sv_undef) || (SvIOK(sv) SvIV(sv) == DONE)) {
+if (!*av) {
+do_register_cleanup = 1;
+}
+if (*av SvREFCNT(*av)) {
+SvREFCNT_dec(*av);
+}
+*av = newAV();
+}
+else if (SvROK(sv) SvTYPE(SvRV(sv)) == SVt_PVAV) {
+*av = (AV*)SvRV(sv);
+++SvREFCNT(*av);
+do_register_cleanup = 1;
}
else {
- croak("Can't set_handler with that value");
+croak("Can't set_handler with that value");
+}
+
+if (do_register_cleanup) {
+register_cleanup(p, (void*)*av, mod_perl_cleanup_av, mod_perl_noop);
}
-save_av-ptr = av;
-register_cleanup(p, save_av, perl_restore_av, mod_perl_noop);
}
-static void set_handler_dir(perl_handler_table *tab, request_rec *r, SV *sv)
+void set_handler_dir(perl_handler_table *tab, request_rec *r, SV *sv)
{
-dPPDIR;
-set_handler_base((void*)cld, tab, r-pool, sv);
+dPPREQ;
+if (!cfg-dir_cfg) {
+cfg-dir_cfg = perl_create_dir_config(r-pool, r-uri);
+}
+set_handler_base((void*)cfg-dir_cfg, tab, r-pool, sv);
}
static void set_handler_srv(perl_handler_table *tab, request_rec *r, SV *sv)
{
-dPSRV(r-server);
-set_handler_base((void*)cls, tab, r-pool, sv);
+dPPREQ;
+if (!cfg-srv_cfg) {
+cfg-srv_cfg = perl_create_server_config(r-pool, NULL);
+}
+set_handler_base((void*)cfg-srv_cfg, tab, r-pool, sv);
}
static perl_handler_table *perl_handler_lookup(char *name)
@@ -185,29 +176,45 @@
return NULL;
}
-
static SV *get_handlers(request_rec *r, char *hook)
{
AV *avcopy;
AV **av;
+dPPREQ;
dPPDIR;
dPSRV(r-server);
void *ptr;
perl_handler_table *tab = perl_handler_lookup(hook);
-if(!tab) return Nullsv;
+if (!tab) {
+return Nullsv;
+}
-if(tab-type == PER_DIR_CONFIG)
- ptr = (void*)cld;
-else
- ptr = (void*)cls;
+if (tab-type == PER_DIR_CONFIG) {
+if (cfg-dir_cfg *avptr_from_offset(cfg-dir_cfg, tab)) {
+ptr = (void*)cfg-dir_cfg;
+}
+else {
+ptr = (void*)cld;
+}
+}
+
Re: Pinning down panic: POPSTACK
On Wed, 28 Jun 2000 [EMAIL PROTECTED] wrote: The modperl archives are pretty clear that panic: POPSTACK errors caused by dies called in a eval is a perl bug. The archives are also clear that this is often a result of an interaction with Apache::Session, which I *was* getting, but have since fixed(?) yes, fixed in Perl 5.6.0. My new problem is that I am getting the error between my PerlAccessHandler and HTML::Mason module. I repeat, the PerlAccessHandler is completely done, and the HTML::Mason handler hasn't been called at all. This is NOT a case of a tied Apache::Session going out of scope when the PerlAccessHandler ends. I think I proved this by putting debugging lines in subs DESTROY and 'save' of Apache::Session.pm. That's what my problem USED to be. :) Doesn't this mean it is happening in mod_perl itself? maybe, are you still having this problem? if you can reproduce it, start httpd like so: % gdb httpd (gdb) b Perl_my_exit (gdb) run -X then make a request that triggers the POPSTACK error, go back to gdb: (gdb) where and post the output of that.
Re: Totally trivial patch
On Mon, 10 Jul 2000 [EMAIL PROTECTED] wrote:
Hi Doug,
I was trying to figure out how to hide part of the URL of an
$r-custom_response from the user and I found this...
It's real trivial, does that matter?
not at all, more than welcome, thanks.
I assume that if (*string == '/') then of course (*string != '"').
I am also assuming that || and work the same in .xs as they would in perl.
yep.
This is a patch against the current CVS.
--- Apache.xs Mon Jun 5 18:20:44 2000
+++ Apache.xs.new Mon Jul 10 11:41:47 2000
@@ -264,7 +264,7 @@
retval = conf-response_code_strings[idx];
if (string) {
conf-response_code_strings[idx] =
- ((is_url(string) || (*string == '/')) (*string != '"')) ?
+ ((is_url(string) (*string != '"')) || (*string == '/')) ?
pstrdup(r-pool, string) : pstrcat(r-pool, "\"", string, NULL);
}
By the way, I know (and am sorry about) the fact that you all have spent
more time reading about this than all the CPU cycles this patch will ever
save combined, I think. And maybe every known compiler sees the issue and
compiles both versions the same way, anyway.
i'm not sure how much it would save, or if compilers would optimize that.
but, feel free to pass along anything else like this, even if it seems
trivial.
Re: $r-get_handlers bug/oversight?
On Tue, 25 Apr 2000, Geoffrey Young wrote:
Hi all...
I've noticed that get_handlers() will return the enabled handlers
for a PerlPostReadRequestHandler, but not when it is specified as a
PerlInitHandler (either by calling
$r-get_handlers('PerlPostReadRequestHandler') or
$r-get_handlers('PerlInitHandler'). It is the same with
PerlHeaderParserHandler. An oversight?
PerlInitHandler is just an alias for PerlPostReadRequestHandler and
PerlHeaderParserHandler. mod_perl can only know at config-time if
InitHandler should be alias to PostReadRequest or HeaderParser, i don't
think get_handlers() can figure out which you mean at request time.
Also, I can't get anything for PerlCleanupHandlers, which kinda
makes sense, since Cleanup isn't really a phase, per se (at least according
to the book). Does it make sense to add this to get_handlers() as well?
the get_handlers() patch posted earlier should enable get/set of
PerlCleanupHandlers.
Re: $r-set_handlers behavior?
On Wed, 26 Apr 2000, Geoffrey Young wrote:
good morning...
I'm a bit confused about $r-set_handlers and $r-push_handlers behavior.
Both are listed in the eagle book as being per-request methods, but man
Apache lists them both as server configuration directives. I think, though,
that I'm seeing set_handlers as persisting with the child and push_handlers
as being per-request. Personally, I'd rather have set_handlers per-request
as well for situations where I want to add a handler but reorder it with the
existing ones as well...
the {get,set}_handlers patch posted earlier should fix this behavior, can
you confirm? push_handlers() should probably also be implemented in terms
of r-per_request_config, rather than %Apache::PerlStackedHandlers.
