RE: CGI::Delete for Apache::Request
well, form_fields() is descriptive and would fit nicely with the other Apache::Table methods (headers_in, etc)... something like that, i was thinking post_data, but that table also has query string data in it, which might from a get. phooey. will you keep parms() around for folks who already have functions built around it? maybe making a clean break with 2.0? sure, i'll make an alias for it.
Re: CGI scripts not executing.Re: works on linux, doesn't work onsun.
On Tue, 16 May 2000 [EMAIL PROTECTED] wrote: Actually, as I found out yesterday, it didn't fix it. I still just get the source. Further information. The symptoms were that I wasn't getting redirected properly. Yesterday some pieces finally came together which put me to the following point. Scripts are still not executing. The script that i was getting, was an error in the way i trapped the domain names. Ie, what I was getting, was one where the host was www rather then the fqdn. So this leaves me back at the origianl point, CGI scripts that are under the handler are not being ran. I've checked, and I do return DECLINED when my handler doesn't need to work with the content. ok, you need to describe what Mf7 does. and what is supposed to handle things if you return DECLINED. when you say 'CGI scripts', do you mean Apache::Registry scripts? even you mean mod_cgi, i didn't see any config to handle either if you return DECLINED from Mf7.
Re: mod_perl + any other DSO module returns no data
On Tue, 16 May 2000, Asghar Nafarieh wrote: I have a linux machine with ssl, php, mod_perl + apache 1.3.12. If I load mod_perl module by idself it works fine. But if I add any other module in conjunction with mod_perl in httpd.conf I get "document has no data". I used both mod_perl 1.21 and mod_perl 1.23 with either perl 5.005_03 and perl 5.6.0 and I still get the same result. I changed the apache to 1.3.9 and I still get the same result. Anybody has any answer? i can only ask again what i asked for last night (below), it may seem painful, but it's faster than guessing. the other solution is for you to link mod_perl static. Date: Mon, 15 May 2000 23:29:35 -0700 (PDT) From: Doug MacEachern [EMAIL PROTECTED] To: Asghar Nafarieh [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Re: mod_perl-perl5.6.0 On Mon, 15 May 2000, Asghar Nafarieh wrote: I did it and still I get the same error. ok, then you'll have to get a stacktrace (see SUPPORT doc for tips), assuming this is a core dump.
Re: Apache::URI doesn't work for me
On Tue, 16 May 2000, Rob Tanner wrote: Hello, I do the following: my $parsed_uri = $r-parsed_uri; my $r_scheme = $parsed_uri-scheme; my $r_host = $parsed_uri-hostinfo; my $r_rpath= $parsed_uri-rpath; my $r_path = $parsed_uri-path; The result is that the scalars $r_scheme and $r_host are empty, and only $r_path and $r_rpath have data in them (and the data is correct). that's because $r-parsed_uri is the parse uri from the http request, which does not contain scheme/hostname/port, unless the request is a proxy request. But, if instead I do, my $me = Apache::URI-parse($r); that's a shortcut for building "self urls", if you don't specify a url, the Apache::URI is filled in with everything it can dig out of the request object (including scheme/hostname/port)
[ANNOUNCE] B-Size-0.04
if you're not familar with B::Size, it was written a while back to answer the question 'why are my httpds so damn BIG?' there are hooks in Apache::Status to measure the size of global/lexical variables and the syntax tree. this is a debugging/educational module, for best results, run httpd in -X mode. and, do not enable on a production server, the code to measure the syntax tree can burn lots of cpu. Changes since 0.03: OnMouseOver displays opcode description in the status window thanks to Charles Lee [EMAIL PROTECTED] for the link attribute magic source code is displayed in its own window use a reasonable size code window instead of the entire file when viewing source code linked to from opcodes number lines in source code windows fixes for 5.6.0 fix for threaded perl [Daniel Sully [EMAIL PROTECTED]]
[ANNOUNCE] mod_perl-1.24
The URL
http://perl.apache.org/dist/mod_perl-1.24.tar.gz
has entered CPAN as
file: $CPAN/authors/id/D/DO/DOUGM/mod_perl-1.24.tar.gz
size: 353562 bytes
md5: 08d0ac4c9e2436fdb038021ae8826a8c
Changes since 1.23:
'sub handler : method {}' is now treated as a method handler
variable $Apache::Server::ConfigTestOnly is set to 1 if Apache
is running in configuration test mode (httpd -t)
[Eric Cholet [EMAIL PROTECTED]]
add PerlAddVar directive, like PerlSetVar, but uses ap_table_add
instead of ap_table_set
Makefile.PL warns about 5.6.0+uselargefiles if USE_APXS
Apache::Table-unset can now be called with an array reference
Apache::PerlRun::flush_namespace fixes, so aliased (imported)
code/hash/array/scalar are undefined without undef-ing the pointed-to
data and without using B.pm, thanks to Richard Chen for the suggestion
document Apache::print's special behavior wrt references
[Jeffrey W. Baker [EMAIL PROTECTED]]
fix core dump triggered by Perldo 'foo.pl'/Perl,
thanks to Robert S. Thau for the spot
pass $Config{ccflags} to apache for 5.6.0+
fix Apache-httpd_conf, thanks to Will Trillich for the spot
fixed 'make clean' to remove FILES = passed to MakeMaker
---
enjoy,
-Doug
RE: CGI::Delete for Apache::Request
On Wed, 17 May 2000, Gunther Birznieks wrote: At 10:45 PM 5/16/00 -0700, Doug MacEachern wrote: well, form_fields() is descriptive and would fit nicely with the other Apache::Table methods (headers_in, etc)... something like that, i was thinking post_data, but that table also has query string data in it, which might from a get. phooey. Why not compromise and call it form_data. :) because query string data isn't part of a 'form' either :) client_data?
Re: multiple copies of a module
On Wed, 17 May 2000, Kees Vonk 7249 24549 wrote: However the URL in the guide: http://perl.apache.org/~dougm/Apache-PerlVINC-0.01.tar.gz does not exist, is there any other place where I can find Apache::PerlVINC? it's there now. and, a reminder from when it was first posted, it's not on cpan because it needs a maintainer (besides me :), anybody interested?
Re: RFC: Apache::Request::Forms (or something similar)
On Wed, 17 May 2000, Peter Haworth wrote: Drew Taylor and I are about to write a subclass of Apache::Request which includes form element generation methods, a la CGI.pm. The current favourite name is Apache::Request::Forms, but we'd like to know if anyone has a better one. The module is currently planned to be fairly bare-boned, only adding form element generation methods for methods which will benefit from CGI.pm-style sticky values, and the parameters these methods take are likely to be a lot more restricted than CGI.pm's (not difficult, really). However, this could change in the unlikely event that we get deluged with feature requests. personally, i'd like to see Apache::HTML for generating html, written in c. something simple along the lines of HTML::AsSubs, then another class to glues it and Apache::Request together that provides CGI.pm features, like 'sticky forms'. but, i haven't given that much thought.
Re: Setting authentication via a PerlInitHandler?
On Wed, 17 May 2000, darren chamberlain wrote:
Hi, all.
I am trying to figure out a way to set a PerlAuthenHandler (using
$r-push_handlers()) from a PerlInitHandler.
#$r-auth_type('Basic');
try $r-connection-auth_type('Basic');
i can't recall if that works quite right either.
#$r-auth_name('Test');
that should work.
#$r-requires([{requirement = 'valid-user',method_mask = -1}]);
this will not. i think a better approach, assuming you want
authentication to be conditional, is to configure Auth{Name,Type} and
require valid-user in httpd.conf so the authentication phase is triggered.
if you decide you don't need to authenticate:
$r-push_handlers(PerlAuthenHandler = \Apache::OK);
that is, you don't actually do any authentication, but apache is happy and
carries on since you return OK. otherwise, push your real authentication
handler.
Re: why a mod_perl module,Footer.pm stop cgi-bin?
On Wed, 17 May 2000, Sam Xie wrote: Hello! All, I am new user on mod_perl, and study it from the book, "Write Apache Modules with Perl and C". I installed a Handler, Footer.pm, in apache by embeding the following lines in the file apache.conf: Alias / /usr/local/share/apache/htdocs/ Location / SetHandlerperl-script PerlHandler Apache::Footer /Location It works but the scripts in /cgi-bin/ do not function at all! If I comment this handler , the cgi-bin works again. I don't know whay? Can somebody tell me the reason and how to overcome this side effect? The code and the system information is appended with this email as follow. that example only works with static text/html pages. have a look at Apache::Sandwich.
Re: passing Apache::File to XS code that expects FILE *?
On Wed, 17 May 2000, Jim Winstead wrote: Is there some trick to passing an Apache::File to a function from an XS module that expects a FILE *? so long as the xsub uses a FILE *, the typemap will take care of the magic. for example, Apache::send_fd() is an xsub that uses the FILE * typemap: use Apache::File (); my $r = shift; $r-send_http_header; my $tmp = Apache::File-tmpfile; print $tmp "hi"; seek $tmp, 0, 0; $r-send_fd($tmp);
Re: libapreq
On Wed, 17 May 2000, Matt Sergeant wrote: Doug, When are you releasing libapreq 0.32? i've been meaning to do that for quite a while. i have a large patch in the queue for improving multipart parsing, but already decided to wait for 0.33 to add that. which leaves a few minor details for 0.32, i'll try to make it happen soon.
Re: passing Apache::File to XS code that expects FILE *?
On Wed, 17 May 2000, Matt Sergeant wrote: Well, this may be true, but if you load IO::File before startup then it's not too big a deal... but it still adds a great deal of bloat to the server. and it's oo interface, while very slick, adds quite a bit of runtime overhead, turn the sugar sour imo.
RE: getting the hostname from a TransHandler
On Wed, 17 May 2000, Geoffrey Young wrote:
after reading about it again, it looks like something of a misnomer - like
it does less parsing of the header and more making it available for
manipulation. but I was able to change $r-uri during PostReadRequest
anyway. it does make sense that all the headers must be read and available
before translation I think, and this is what I've seen in practice...
anyway, at this point I default to those who were around earlier and
understand where the HeaderParser phase gets its name/roots... :)
yeah, the name is a little misleading. it's original intent was to allow
modules to take action based on the already parsed headers early on in
the request. which PostReadRequest can also do (and was introduced long
after HeaderParser), but is per-server, whereas HeaderParser is
per-{location,file,directory,etc}
Re: converting CGI scripts to mod_perl and memory use...
On Wed, 17 May 2000, Dave DeMaagd wrote: I'm in the midst of converting a script I wrote in a CGI environment to mod_perl (using Apache::Registry). The scripts are running fine (after a little tweaking to get rid of globals and whatnot), but I am still looking for more ways to keep memory consumption under control, and for ways to check to see /where/ it's going out the window when it is. this message from last night was intended to remind of one way to do that.. Date: Tue, 16 May 2000 23:13:19 -0700 (PDT) From: Doug MacEachern [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [ANNOUNCE] B-Size-0.04 if you're not familar with B::Size, it was written a while back to answer the question 'why are my httpds so damn BIG?' there are hooks in Apache::Status to measure the size of global/lexical variables and the syntax tree. this is a debugging/educational module, for best results, run httpd in -X mode. and, do not enable on a production server, the code to measure the syntax tree can burn lots of cpu. ...
RE: CGI::Delete for Apache::Request
say, rfc's are good for something after all ;) ok, form_data() it is!
Re: passing Apache::File to XS code that expects FILE *?
On Thu, 18 May 2000, Vivek Khera wrote:
"DM" == Doug MacEachern [EMAIL PROTECTED] writes:
DM On Wed, 17 May 2000, Matt Sergeant wrote:
Well, this may be true, but if you load IO::File before startup then it's
not too big a deal...
DM but it still adds a great deal of bloat to the server. and it's oo
DM interface, while very slick, adds quite a bit of runtime overhead, turn
DM the sugar sour imo.
In an embedded environment like mod_perl, then how do you suggest to
deal with the dangling file handles problem? That is, I'm processing
a file or two, and some error occurs. In a normal perl program, I'd
exit or return out and then when the program terminates, it
automagically closes all the files. In mod_perl, the auto-close
doesn't happen until much later. With the OO interface, when the
handle goes out of scope, such as a function call return, the file is
implicitly closed.
What other mechanism do you propose to handle this situation other
than IO::File? I use it all the time myself.
in addition to stas' hints, even local *FH does the job, e.g.:
#/dev/null so strace output is more readable
open my $fh, "/dev/null";
select $fh;
$| = 1;
{
print "enter";
local *FH;
open FH, $0;
print "leave"
}
print "done";
% strace ~/test/io.pl
write(3, "enter", 5)= 5
- open("/home/dougm/test/io.pl", O_RDONLY) = 4
fstat(4, {st_mode=S_ISGID|S_ISVTX|0401, st_size=0, ...}) = 0
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
write(3, "leave", 5)= 5
- close(4)= 0
write(3, "done", 4) = 4
Re: RFC: Apache::Request::Forms (or something similar)
i do think that doug's separation of responsibilities into classes is the right one. your widget toolkit probably shouldn't be named Apache::HTML tho, unless it's actually using the apache api in some fashion. one reason i was thinking Apache::HTML is so we can use ap_pool for allocations.
Re: writing code that works on machines with or without mod_perl
On Thu, 18 May 2000, Matt Sergeant wrote:
On Thu, 18 May 2000, Kenneth Lee wrote:
modperlers,
does it make sense if i put some mod_perl specific codes inside
an eval() so that the code runs on machines that have or haven't
mod_perl installed?
eval 'MOD_PERL_CODE' if $ENV{MOD_PERL};
use Apache ();
my $r = Apache-request;
...
MOD_PERL_CODE
Better still:
eval {
die unless $ENV{MOD_PERL};
require Apache;
my $r = $Apache-request;
...
};
Then you've got no (at least much less than the above) run-time overhead.
better still:
use constant IS_MODPERL = $ENV{MOD_PERL};
BEGIN {
import Apache::Constants qw(OK) if IS_MODPERL;
}
if (IS_MODPERL) {
my $r = Apache-request;
}
_zero_ runtime overhead, since IS_MODPERL is constant folded, that block
is optimized away at compile time outside of mod_perl.
you shouldn't need to 'use Apache ()', mod_perl does that for you, along
with Apache::Constants. in any case, have your startup script require any
Apache:: modules you need and import in a BEGIN block if needed.
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, Autarch wrote: C seems like serious overkill for something to simply generate plain text output. How slow is making a string in perl compared to doing it in C? I can't imagine there's to much of a difference. more like Perl is serious overkill :) SV's are BIG, notice the $unused variable and the B::TerseSize output (from Apache::Status) below, even before a string is copied into it, there's 48 bytes eaten. my $r = shift; $r-send_http_header; my $unused; my $string = "hi"; print $string; Totals: 1455 bytes | 23 OPs PADLIST summary: 0: undef [AV 116 bytes] MAX = 3 1: $r [RV52 bytes] 0x891b9b4 2: undef [GV81 bytes] 3: undef [NULL 24 bytes] 0x891ba44 4: undef [NULL 24 bytes] 0x891ba5c 5: $unused [NULL 48 bytes] 0x891ba50 6: $string [PV63 bytes] hi now let's look at CGI::start_html: Totals: 15595 bytes | 330 OPs PADLIST summary: 8:$title [PV78 bytes] Untitled Document 35: undef [PV 140 bytes] !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd" 40: undef [PV56 bytes] HTMLHEADTITLE 46: undef [PV81 bytes] HTMLHEADTITLEUntitled Document/TITLE 48: undef [PV65 bytes] LINK REV=MADE HREF="mailto: 59: undef [PV49 bytes] BASE HREF=" 77: undef [PV48 bytes] NOSCRIPT 94: undef [PV49 bytes] /HEADBODY 96: undef [PV50 bytes] /HEADBODY 100: undef [PV45 bytes] /TITLE 101: undef [PV 199 bytes] !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd" HTMLHEADTITLEUntitled Document/TITLE /HEADBODY i've omitted all but the string variables, notice the additional copies, which are a result of concatination. Perl copies *everything* and these copies add up to alot. this is why i would like to see an html generator written in c, it would result in a much smaller footprint, no matter what the Perl implementation may be.
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, brian moseley wrote:
On Thu, 18 May 2000, Jeffrey W. Baker wrote:
.= concatenation is way faster
i don't have any results to back up my claim. therefore,
my words are eaten :)
i was convinced tho, even way back before you came to cp. i
wonder what convinced me!
that was probably me :) but, i don't recall suggesting join.
but i do recall pushing away from concat when print()-ing, this benchmark
also illustrates why i made Apache::print dereference references to
strings. 5.005_03 does seem todo better with the array benchmark than
5.006, oh well. there's tradeoffs both ways, i don't think there's a
clear winner.
Benchmark: timing 3 iterations of array, concat, ref_array...
array: 8 wallclock secs ( 6.90 usr + 0.27 sys = 7.17 CPU) @4184.10/s (n=3)
concat: 7 wallclock secs ( 5.98 usr + 0.16 sys = 6.14 CPU) @4885.99/s (n=3)
ref_array: 5 wallclock secs ( 4.59 usr + 0.16 sys = 4.75 CPU) @6315.79/s (n=3)
use Benchmark;
open my $fh, "/dev/null" or die;
my($one, $two, $three) = map { $_ x 4096 } 'a'..'c';
timethese(30_000, {
'ref_array' = sub {
my @a;
push @a, \($one, $two, $three);
my_print(@a);
},
'array' = sub {
my @a;
push @a, $one, $two, $three;
my_print(@a);
},
'concat' = sub {
my $s;
$s .= $one;
$s .= $two;
$s .= $three;
my_print($s);
},
});
sub my_print {
for (@_) {
print $fh ref($_) ? $$_ : $_;
}
}
Re: RFC: Apache::Request::Forms (or something similar)
On Fri, 19 May 2000, Gunther Birznieks wrote: eg I think there was a thread on this list way back about OO method calls versus direct package references... and people said that OO method calls have a lot of overhead, but I think in later versions of Perl, OO method call paths are cached(?) and so method calls no longer have the same overhead as they used to. there has always been a method cache, but even with that, methods are still a bit more expensive. the only improvement in 5.6.0 related to method calls (that i know of ) is that: $obj-method; #where method name is constant, know at compile time is now faster than: $obj-$method; #where $method isn't known until runtime
Re: Prb: Apache::DB plus Perl 5.6 doesn't break
i hadn't tried Apache::DB with newer Perl since 5.005_6x-ish, there was a fix that went into version 0.06 for that, are you using 0.06? i am able to set breakpoints no problem with 5.6.0 (perl-current, actually). i would suggest stripping back your Perl config to something simple (i tested with b Apache::Status::handler) and make sure require Apache::DB/Apache::DB-init is the first piece of Perl code to run.
Re: Prb: Apache::DB plus Perl 5.6 doesn't break
On Fri, 19 May 2000, Jeremy Howard wrote: Thanks heaps, Doug--moving require Apache::DB/Apache::DB-init to the top fixed it! kool! Previously I had 'use Apache' 1st, which worked fine under the "old" version... It's funny the things that change between versions, isn't it? In fact, Apache::DB is now working better than before--I used to have some subs outside of modules that wouldn't break properly... now they work fine! right, because Perl decides at compile time if a subroutine call should be dispatched to the debugger, which it won't do unless Apache::DB-init has been called (similar to what -d switch does on the command line) Is anyone aware of any specific reason not to switch to 5.6.0 with mod_perl for production machines (other than just 'in case')? we've hit a few problems, but 1.24 should have them ironed out. can't promise there won't be more though.
Re: RFC: Apache::Request::Forms (or something similar)
On Fri, 19 May 2000, Autarch wrote: Well, my point was that the decision to code something in C should be done because it offers an overwhelming (orders of magnitude) improvement, preferably on more than one front (speed, memory, ease of maintenance (haha) ). small savings here and there can add up to big savings in the end. did you look at the size of CGI::start_html? 16k. and that's a small subroutine, these things add up quick. Really, if you feel that Perl is too memory hungry and slow for even simple text output, then why use Perl at all? i never said that. i'm just trying to point out that it's worth considering the savings. My bias is against C because I don't like it and I think it makes the module less accessible to people and therefore less likely to get improved by the community at large, and more likely to only get worked on by 1 person. personally, i like to have generic things written in c, things that won't change much or at all after they are first implemented (not including bug shaking). e.g. Apache::Request. both c and Perl are great languages and blend very well together. both have pros and cons, i try to use the right combo of both to balance these out. c is smaller. c is faster. Perl is much easier to code than c, so i like to save it for things that are difficult to code. generating html is not difficult. is it really worth the time to implement this in c? i'm not convinced yet either, but it is worth thinking about. we need to consider these things if we want to see the Apache/Perl combo improve as a development platform. think big picture.
RE: PerlFreshRestart Question/Problem
On Fri, 19 May 2000, Stas Bekman wrote: Huh? Wasn't the mod_perl 1.23 supposed to fix this problem with DSO? I thought to remove this item from the Guide. Are there still problems with DSO? If I remember correctly the problem was of broken internal pointers when the DSO code was reloaded. not quite, the bogus pointers problem was triggered by: LoadModule perl_module libmodperl.so being called twice. not by PerlFreshRestart. any how, dso issues are not 100% ironed out, see Makefile.PL:malloc_check() for example.
Re: RFC: Apache::Request::Forms (or something similar)
On Fri, 19 May 2000, Matt Sergeant wrote: Damn - forgot smiley. Sorry :-) doh. your reponse combined with my jetlag == foncusion :-)
Re: Apache::PerlVINC
On Thu, 18 May 2000, Kees Vonk 7249 24549 wrote: I am testing the use of Apache::PerlVINC but I think I must do something wrong because I get an error on the PerlRequire statement in the following bit of httpd.conf when starting apache: PerlINC /opt/ward/IDV/DEV/Modules PerlRequire Ward/IDV/IDVDatabase.pm PerlINC modifies @INC at request time to pick up the different version of your PerlRequire'd module. however, mod_perl needs to be able to find this module at startup time as well. you'll need to 'use lib ...' or similar so your PerlRequire'd module can be found at startup time if it's not already somewhere in @INC.
Re: segfault: perl 5.6.0, apache 1.3.12, mod_perl 1.24 and XML::Parser
On Sat, 20 May 2000, Matthew Darwin wrote: My apache dies about 30% of the time when handling any mod_perl request that requires XML::Parser. Any other page (even pages that use mod_perl) are 100% ok. Are there any known issues with this (besides the requirement for --disable-rule=expat)? This all worked fine with perl 5.005_03 + mod_perl 1.23. I'll get more info if nobody has seen this before. double check that Apache is being built with the CFLAGS you set for large file support. other than that, you'll need to get a stacktrace (see SUPPORT doc)
Re: Project Information
On Sun, 21 May 2000, Allen Wilson wrote: Good afternoon... My name is Allen Wilson and I am looking to join a mod-perl team. If there are any positions available on current projects, I would appreciate any information pertaining to the project and the available positions. most people join the project simply by: -helping to answer questions and join in discussions on this list -implementing an Apache:: module which can be useful to others and distributing it on cpan for others to use and contribute to -helping to spot/fix bugs found in the 1.xx version, including known/unresolved issues in the todo file there will also be lots of room to help with the upcoming 2.0 version, which you can access via cvs: http://perl.apache.org/mod_perl_cvs.html just change 'co modperl' to 'co modperl-2.0' i plan to write up an outline of all the missing pieces soon to make it easier for folks to join in.
Re: scalar(%hash) gives zero
On Mon, 22 May 2000, Kenneth Lee wrote: My script has these lines in it, my %in; CGI::ReadParse(\%in); print scalar(%in); print %in; Then I run it under shell, bash$ ./myscript.pl foo=1 bar=2 It gives me 0foo1bar2 Can anyone explain why the "0" but not the bucket usage? because %in is a tied hash (tied by ReadParse), nothing is ever stored inside that hash, the tied methods use the object which is tied to it to get/set data. so, there is no 'bucket usage', same as: % perl -e 'print scalar %hash' 0
Re: ap_add_version_componen
On Mon, 22 May 2000, Emmanuel PIERRE wrote: is there a way to modify ap_add_version_componen from mod_perl ? no. why do you need to do that?
Re: strange httpd mod_perl segfault details
On Mon, 22 May 2000, Roger Foskett (2) wrote: MOD_PERL VERSION mod_perl-1.23 - MOD_PERL CONFIGURATION perl ./Makefile.PL \ USE_APXS=1 \ WITH_APXS=/usr/local/apache/bin/apxs \ EVERYTHING=1 thanks for the complete bug report, if only you had tried the latest version (1.24), Makefile.PL explains the problem/solution(s): Your Perl is uselargefiles enabled, but Apache is not, suggestions: *) Rebuild Apache with CFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" *) Rebuild Perl with Configure -Uuselargefiles *) Let mod_perl build Apache (USE_DSO=1 instead of USE_APXS=1) pick the least painful of those three and your problem will be gone.
Re: mod_perl 1.24, nmake test causes Apache Win32 to crash.
On Sat, 20 May 2000, Thomas wrote:
hi,
I've run into some oddities..
running nmake test causes to seriously crash
at "internal/table" while the same test with 1.22 passes fine.
Test "internal/api" FAILS for both 1.22 / 1.24
Both are compiled with identical setups using VC6 / WinNT
with the 1.3.12 / 5.00503 libs .
suggestions, anyone ??
randy found the problem, the patch below is in cvs now..
--- src/modules/perl/Table.xs 2000/05/12 22:45:32 1.9
+++ src/modules/perl/Table.xs 2000/05/23 15:56:12 1.10
@@ -58,7 +58,11 @@
}
-static void table_delete(table *tab, const char *key, const char *val)
+static void
+#ifdef WIN32
+_stdcall
+#endif
+table_delete(table *tab, const char *key, const char *val)
{
table_unset(tab, val);
}
Re: Cookies
On Mon, 22 May 2000, Jim Serio wrote: I'm still having trouble writing cookies while using Apache::Sandwich (thanks Vivek for the explination). Searching through the list archives, I found an example from David Pisoni to add the cookie to an image using the PerlFixupHandler. It doesn't seem to be workign for me though.. I also tried using CGI (in the handler) to write out the cooke with the same results. Here's the snippet from httpd.conf: Location /images/header_top_left.gif PerlFixupHandler Cookieme /Location And here's teh entire Cookieme module: i dropped your code in mod_perl-1.xx/t/docs/startup.pl and config in t/conf/httpd.conf (in the /perl/perl-status Location), it works just fine. your cookie format looks wrong though, maybe netscape can't parse it? % telnet localhost 8529 Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. GET /perl/perl-status http/1.0 HTTP/1.1 200 OK Date: Tue, 23 May 2000 18:07:06 GMT Server: Apache/1.3.13-dev (Unix) mod_perl/1.24_01-dev Perl/v5.6.0 Set-Cookie: cobrand=cobrand= ;domain=.hotwired.com;path=/ Connection: close Content-Type: text/html ...
Re: Apache::DBI
On Mon, 22 May 2000, Mark Holt wrote: Newbie to the list, apologies if this is a FAQ, but I checked the archives... I built a modperl-enabled server, (Apache/1.3.9 Ben-SSL/1.37 (Unix) mod_perl/1.21) and have been running it for some time. I have the sounds like you need upgrade your mod_perl, dso fixes happened post-1.21
Re: Apache::PerlVINC
On Tue, 23 May 2000, Kees Vonk 7249 24549 wrote:
Ok, I have added 'use lib qw(/opt/ward/IDV/DEV/Modules);' to my startup.pl,
but now I get the following error in my error log:
Syntax error on line 339 of /opt/ward/apache/conf/httpd.conf:
Invalid command 'PerlINC', perhaps mis-spelled or defined by a module not
included in the server configuration
try this in httpd.conf:
Perl
delete $INC{'Apache/PerlVINC.pm'};
require Apache::PerlVINC;
/Perl
mod_perl is supposed to do that for you, so the module is reloaded again
when apache re-reads it's configuration on startup.
Re: Apache::Util gives segfault
On Tue, 23 May 2000, Kenneth Lee wrote:
When I pass an undef (or "", maybe) to Apache::Util-unescape_uri_info
it gives me segfault.
Any idea?
i'm surprised this hasn't bitten anybody before. thanks for the
report, patch below.
--- src/modules/perl/Apache.xs 2000/04/21 06:03:52 1.96
+++ src/modules/perl/Apache.xs 2000/05/23 18:06:21
@@ -668,6 +672,10 @@
CODE:
register char * trans = url ;
char digit ;
+
+if (!url || !*url) {
+XSRETURN_UNDEF;
+}
RETVAL = url;
Re: mod_perl 1.24 testing keeps failing
On Tue, 23 May 2000, Mark Murphy wrote: I'm having a problem with the make test in mod_perl 1.24. It doesn't seem to be configured correctly. Here are the steps I've taken so far. Invalid command 'PerlTaintCheck', perhaps mis-spelled or defined by a module not this indicates that mod_perl is not configured with your server. try building using the steps in INSTALL.simple.mod_ssl
Re: Variable value seems to change on it own (huh!)
sub parse_response {
sub process_tag {
}
}
why do you nest this subroutine? the guide and other docs explain the
"variable will not stay shared" problem that normally bites people under
Apache::Registry. just move the process_tag subroutine declaration
outside of parse_response:
sub parse_response {
...
}
sub process_tag {
}
Re: global variables and reparsing (short reproducible example)
On Tue, 23 May 2000, Marc Lehmann wrote: As a related note, I wondered why there isn't a mod_perl callback that is clled _before_ forking, but after configuration parsing. This would allow a lot of data sharing between the httpd servers. My module requires you to call "configured PApp" at the end of the configuration section so that it can pull in most of the code and big data structures before it forks (so the data gets shared). AFAIK there is no way to make this automatic. what's wrong with having 'PerlModule foo' at the bottom of your config file? apache 1.3 has no 'post-config' hook, 2.0 does though. Then, when the file is parsed again, _another_ instance of $global gets PerlFreshRestart On PerlModule X The module is indeed compiled twice. yes, because apache does module-init/config-read twice at startup, since you have 'PerlFreshRestart On', your module is re-compiled on this second pass.
Re: Apache::Resource on Linux
On Mon, 22 May 2000, Ian Kallen wrote:
BSD::Resource passed all of the make test tests but when I tried enabling
Apache::Resource on a rh6.1 installation the error log barfed with these:
Ouch! malloc failed in malloc_block()
on problem is that the values were not coverted to MB, patch below fixes
that. this error is correct when the limit has been reached and clearly
isn't graceful, you might want to use Apache::SizeLimit instead.
--- lib/Apache/Resource.pm 2000/03/23 04:48:56 1.9
+++ lib/Apache/Resource.pm 2000/05/23 18:41:44
@@ -26,7 +26,7 @@
sub DEFAULT_RLIMIT_FSIZE () { 10 } #file size (MB)
sub DEFAULT_RLIMIT_STACK () { 20 } #stack size (MB)
-my %is_mb = map {$_,1} qw{DATA RSS STACK FSIZE CORE MEMLOCK};
+my %is_mb = map {$_,1} qw{DATA RSS STACK FSIZE CORE MEMLOCK AS};
sub debug { print STDERR @_ if $Debug }
Re: Segmentation fault (11) with mod_perl 1.23...
On Tue, 23 May 2000, Mark Haviland wrote: Doug, Sorry for the consistent eMails, but I guess I wasn't entirely correct in my statment about my version of perl being the problem. After some more tests, I've found that things go wrong (ie. I get a Segfault) when I attempt to pre load the Sybase::CTlib module (or any module that uses it) in the PerlRequire file. But, when I have the 'use Sybase::CTlib' inside of my handler, then everything is ok. the next step would be to get a stacktrace (mod_perl built with PERL_DEBUG=1 prefered), see the SUPPORT doc for hints.
Re: Problem compiling mod_perl 1.24 on Solaris 2.6
On Tue, 23 May 2000, Fred Miller wrote: On 4/26/2000, Steve Hay wrote about "Problem compiling mod_perl 1.23 on Solaris 2.4" I am experiencing what appears to be a very similar problem, but with more recent modules and OS. I am running mod_perl 1.24, Perl 5.6.0, Apache 1.3.12, Solaris 2.6 perl -V would help. is your cc gcc or sun's? looking at the line number, i would try replacing any occurance of: perl_eval_sv - eval_sv perl_call_sv - call_sv perl_call_pv - call_pv why your compiler is tripping on those macros, i have no idea.
Re: overriding warn()
On Tue, 23 May 2000, Amy wrote: Is there an easy way to override warn() the way Apache overrides die() - I'm trying to disable warn() calls in production without changing any code. I think I should probably be using Apache::Log, but is there an easier way to accomplish this without changing code? you can: use Apache qw(warn); which overrides the builtin with Apache::warn. to enable those warnings, in httpd.conf: LogLevel warn (or debug) to disable: LogLevel error
Re: mod_perl 1.24 / DBD:: Sybase - Can't find loadable object
On Tue, 23 May 2000, Graf, Chris wrote: This is driving me crazy. I upgraded Perl to 5.6 (from 5.005) and mod_perl to 1.24 (from 1.22) trying to correct weird DBD::Sybase errors somehow related to decaying connections. are you sure it was properly installed? do you get errors with this? % perl -MDBD::Sybase -e0
Re: global variables and reparsing question (low priority ;)
On Tue, 23 May 2000, Marc Lehmann wrote: At leats in the example I sent in there is no sign of any closure. There is a closure, and this might be the thing that's making trouble for you, or at least part of it. This is a closure: that example is only a closure if it's compiled by Apache::Registry, which, is not in this case.
Re: mod_perl 1.24 testing keeps failing
On Tue, 23 May 2000, Mark Murphy wrote:
Here is some more information I gathered from trying the "make test" under
mod_perl. I ran the command by hand and discovered that I'm getting a core dump.
(gdb) backtrace
#0 0xff1c5568 in _smalloc () from /usr/lib/libc.so.1
#1 0xff1c55ac in malloc () from /usr/lib/libc.so.1
#2 0xff0e2940 in Perl_savepvn ()
ah, looks like typical solaris dso problem, which mod_perl's Makefile.PL
should have warned you about and suggested solutions to pick from:
if ($] 5.006) {
phat_warn(EOF, $abort);
Your current configuration will most likely trigger core dumps,
suggestions:
*) Do not configure mod_perl as a DSO
*) Upgrade your Perl version to 5.6.0 or higher (w/ -Ubincompat5005)
*) Configure Perl with -Uusemymalloc (not recommended for performance)
EOF
}
elsif ($bincompat) {
phat_warn(EOF, $abort);
Your current configuration will most likely trigger core dumps,
suggestions:
*) Do not configure mod_perl as a DSO
*) Rebuild Perl without malloc pollution (Configure -Ubincompat5005)
EOF
}
Re: global variables and reparsing (short reproducible example)
On Tue, 23 May 2000, Perrin Harkins wrote: Your sub x is a closure. That's why it returns the previous value of $x. When it gets re-defined, it should start looking at the value of the new $x. nevermind what i said in the other reply about not being a closure. you're right, it is by definition, i just assumed you were refering to the Apache::Registry trap.
Re: global variables and reparsing question (low priority ;)
On Wed, 24 May 2000, Marc Lehmann wrote:
You must be kidding here!!! Using lexicals on package level is broken??? If
it is broken, then _why_ is it recommended programming practise in perl (see
perltoot for example)?
i'm not kidding. i don't understand whay you mean by 'using lexicals on
package level is broken'. i see no problem with that. maybe you could
post an example, your first one, as you said yourself, was broken. here's
a tiny example that is not broken:
% cat MyTest.pm
package MyTest;
my $x = 0;
sub inc_x {
$x++;
}
sub print_x {
print "x=$x\n";
}
print "MyTest loaded\n";
1;
% cat test.pl
for (1..2) {
delete $INC{'MyTest.pm'};
require MyTest;
for (1..5) {
MyTest::inc_x();
MyTest::print_x();
}
}
% perl test.pl
MyTest loaded
x=1
x=2
x=3
x=4
x=5
MyTest loaded
x=1
x=2
x=3
x=4
x=5
are you expecting different results?
and, like i said, i realize that certain modules make assumptions that
they will only be loaded once in the same process and that re-parsing them
can uncover subtle problems. but i still consider such assumptions to be
broken.
Re: Problem compiling mod_perl 1.24 on Solaris 2.6
On Wed, 24 May 2000, Fred Miller wrote: Like I said, I'm a bit naive in these matters. I didn't specify using gcc or cc. I used the same path to compile Perl, Apache, and Mod_Perl. When I aaksed which gcc and which cc, my machine does report gcc appearing in my path ahead of cc. Could that be the problem? i could try re-building Perl like so: % ./Configure -des -Dcc=gcc make test make install that is, go with all the defaults, but force Perl to use gcc.
Re: CORE::exit and Apache:Registry
On Wed, 24 May 2000, Mark Hewis wrote:
As far as I have tested under Apache::Registry the following commands have
the following effect
1) CORE::exit - restart all child processes for that server ( a little too
drastic for me)
that shouldn't happen. it should only kill the kid it was called from.
2) exit - exit code but leave state of all modules the same
What am am really after is an exit which just restarts the child process (it
is called in) resetting all module globals any suggestions?
exit(-2) will do a graceful exit of the child (unlike CORE::exit), after
logging the transaction is done and connection is closed.
On a related topic in a given module
BEGIN{} seems to be called only on child initialisation while
END{} is called at the end of each processed request
This seems a little inconsistant why is this? Can this behaviour be changed?
Because of this
close_everything() in END{} in BerkeleyDB.pm is called after each request
destroying any ties or environments open which for me is not good.
see mod_perl.pod and chapter 9 of the eagle book for BEGIN/END details.
the solution for you would be to load BerkeleyDB at startup, in which
case, END is not called until the child exits.
Re: global variables and reparsing (short reproducible example)
On Wed, 24 May 2000, Perrin Harkins wrote: On Wed, 24 May 2000, Marc Lehmann wrote: I was under the impression that you cannot configure Apache from a PerlRequire. If that is not the case (and somehow works) I'd really like to get away from perlsections. You can only configure Apache from Perl sections, but you can load all your modules, shared data, etc. from a file pulled in with PerlRequire. actually you can, if a module defines variables in the Apache::ReadConfig:: namespace, they are fed to the apache config gears just as Perl sections are.
Re: Apache::Registry script problem
On Wed, 24 May 2000, Drew Taylor wrote: Hi all, I'm having a serious, but intermittent, problem with my Apache::Registry scripts. I have 2 (soon to be more!) site running on the same physical server. Each site is driven by a set of short perl-script scripts. The scripts execute code in OO modules that are shared among all servers. The scripts are identical between all sites except for the following: (index.pl) my $SITENAME = 'cloudstock'; my $SITEID = 1; OR my $SITENAME = 'wiredstock'; my $SITEID = 2; (all others in /cgi-bin) my $search = eLogix::Search-new($CGI, 'cloudstock', 1); $search-blah OR my $search = eLogix::Search-new($CGI, 'wiredstock', 2); $search-blah ETC The part that changes is the 'cloudstock' and '1'. However, I occasionally (and not reliably) get a page from cloudstock.com using the wiredstock.com scripts! On some debugging, I can verify that when this happens the script has the wrong values. It seems that apache is confused and sometimes serves the wrong script for the given domain! sounds like the 'variable won't stay shared' problem, see http://perl.apache.org/guide/
Re: difference between ...
On Wed, 24 May 2000, David Hajoglou wrote: Would there ever be any difference between the output of the following: (looking on the mod_perl quick reference card) From Apache::URI $str = $uri-query() From Request object $str = $r-args(); As far as what they hold about the request, would these ever differ, or do they access the same data (in different ways)? they are the same, see http_protocol.c: r-args = r-parsed_uri.query;
Re: httpd exits with apache-1.3.12 and mod_perl-1.21 on Redhat 6.2
On Wed, 24 May 2000, Roberto Bourgonjen wrote: Hi all, I am encountering strange problems on redhat 6.2 installations with rpm's apache-1.3.12-2 and mod_perl-1.21-10 (the latest available versions from redhat. I _have_ to use rpm's). I've tried two machines. As soon as load certain modules the server exits immediately, without producing the slightest error message. try this: % gdb httpd (gdb) b exit (gdb) run -X whether it core dumps or exit() is called, post the output of: (gdb) bt
Re: Need help in compiling the mod-perl
On Wed, 24 May 2000, Seshagiri Rao Maddirala wrote: Hi, I am tryong to compile modperl with gcc2.8.1 on solaris 7. Even before make finishes I get out with error: mod_perl.c at line 278 'aptestconfigonly' - Unresolved symbol. I picked it up today afternoon from ftp site of perl.apache.org. similar to that) and log file shows up that apache 1.3.6 with try apache 1.3.12
Re: PerlTransHandler
On Thu, 25 May 2000, Sergey Ivanyuk wrote: Hi All. I'm having problems with the PerlTransHandler handler. I would like to only translate some requests, but keep Aliases working. However, I just can't get that done. If I use a simple 'return DECLINED;', all my cgi scripts and aliases directories return 'Not found'. I know the handler is executed, and if I remove it from httpd.conf, everything works fine. What am I doing wrong? Should a simple 'return DECLINED;' run default handlers, or am I missing something? Thanks in advance. return DECLINED; should work fine. can you post a tiny example config and handler? Apache::ShowRequest (part of the Apache::Module package on CPAN) can also help debug this sort of problem.
Re: CGI.pm broken with Apache/mod_perl/warnings? (was Re: XHTML_DTDredefined?)
On 25 May 2000, Randal L. Schwartz wrote:
Yeah, it's CGI.pm alright. So do I complain to Lincoln to fix it, or
is it just a synergy thing between mod_perl, Apache, and CGI.pm that I'll
have to live with?
are you re-loading CGI.pm? that's the only way this warning can be
triggered, from what i can see. in which case, this wouldn't be a bug in
CGI.pm, the re-loader simply needs:
{
no warnings;
}
Re: GET html page - permission denied
On Thu, 25 May 2000, Prasit P wrote: Hi guys, I've built Apache 1.3.12 with mod_perl 1.21. try upgrading mod_perl, 1.22 has this change: =item 1.22 - March 22, 2000 proxy support fixed wrt RFC2068, thanks to Benjamin Elijah Griffin for the spot
Re: Search for Apache::Safe
On Thu, 25 May 2000, Alexander Lazic wrote: hi, i search for the Apache::Safe Module which isn´t in mod_perl-1.24 included. it doesn't exist. i had written a version once, but wasn't happy with it. there is an experimental PerlOpmask directive that was added to mod_perl in 1.15_01 (see Changes 9/98), but i haven't looked at since. this directive is intended to mask op codes (e.g. system, backticks) and skips the namespace protection that Safe.pm attempts to provide, that simply cause too much trouble when trying to implement Apache::Safe.
Re: REPOST: Limiting Resources
On Thu, 25 May 2000, Suresh wrote: I am trying to limit the execution of a mod_perl script by setting the limit of RLimitCPU. But this does not seem to work. I am using apache 1.3.12 , mod_perl. I tired using the module Apache::Resource but even that did not work. Does any body know why this is or am i missing something. no clue. you don't mention what os or what Apache::Resource config you are using.
Re: REPOST: Limiting Resources
On Thu, 25 May 2000, Vivek Khera wrote: limit of RLimitCPU. But No; you are wrong. wrt RLimitCPU and friends, he is right. the built-in apache RLimit directives only work for mod_cgi processes, which are set in ap_call_exec(). hmm, i bet the RLimit* directives could be moved to a child_init handler, in which case, they should work for mod_perl processes and we wouldn't need Apache::Resource.
Re: mod_perl 1.24 testing keeps failing
On Thu, 25 May 2000, Mark Murphy wrote: sh Configure -Dcc=gcc -Ubincompat5005 hmm, i've seen a similar report related to largefile support, try once more with: sh Configure -Dcc=gcc -Ubincompat5005 -Uuselargefiles
Re: Apache::Registry script problem
On Thu, 25 May 2000, Drew Taylor wrote: I have tried many things to solve this problem. Many thanks go to Geoffrey Young who helped me privately (and clued me into a great solution to another future maintenance problem as well!). i glad your problem is solved, but can we keep all help on the list to prevent duplication of efforts? i get the feeling this is happening alot. it's a pity for folks to take time trying to help solve a problem that's already been solved :)
Re: PerlTransHandler
On Thu, 25 May 2000, Sergey Ivanyuk wrote:
package handler;
use Apache;
sub handler {
return DECLINED;
}
where does DECLINED come from? watch what happens if you add 'print
handler()' and run it from the command line, and watch what happens when
you add 'use strict;'. adding 'use Apache::Constants qw(DECLINED)' will
fix your problem.
Re: mod_perl 1.24 testing keeps failing
On Thu, 25 May 2000, Mark Murphy wrote: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' those are the flags added when largefile support is enabled. try with a fresh source tree and run: sh Configure -des -Dcc=gcc -Ubincompat5005 -Uuselargefiles -des will use all defaults except those you override and you don't have to answer all those darn questions.
Re: httpd exits with apache-1.3.12 and mod_perl-1.21 on Redhat 6.2
On Thu, 25 May 2000, Roberto Bourgonjen wrote: rpm's apache-1.3.12-2 and mod_perl-1.21-10 (the latest available whoops, i missed your version. if you're trying to use mod_perl as a dso, upgrade to 1.24.
Re: GET html page - permission denied
On Thu, 25 May 2000, Prasit P wrote: Thank guys for your answer. I've just tried using Apache 1.3.12, and mod_perl 1.24, all downloaded today, but it's the same problem. seems that only works when you use http://hostname, both mod_proxy and mod_perl use logic like so: !(r-parsed_uri.hostname strEQ(r-parsed_uri.scheme, ap_http_method(r)) ap_matches_request_vhost(r, r-parsed_uri.hostname, r-parsed_uri.port_str ? r-parsed_uri.port : ap_default_port(r))); logic could probably be added to compare the ip addresses, but why do you need to do that anyhow? what's wrong with using 'GET /index.html http/1.0' ?
Re: Bugs 5.6.0 modperl use?
On Thu, 25 May 2000, Jeremy Howard wrote:
CGI::Carp preloaded.
DBI preloaded.
[Wed May 24 19:58:28 2000] [error] PerlRun: `Bizarre copy of HASH in aassign
at /usr5/perl/lib/5.6.0/Carp/Heavy.pm line 79.
...
Anyone else seen these?
Oh yes, I've been battling that tonight...
Do the following:
In Carp::Heavy, change 'DB' to 'DB_tmp':
Line 39: while (do { { package DB_tmp; @a = caller($i++) } } ) {
Line 79: @a = @{DB_tmp::args}; # must get local copy of args
In CGI::Carp, change Line 257:
FROM: my $message = shift;
TO: my ($message) = @_;
Yes, this really does matter--I carefully reproduced a problem that only
occured when 'shift' was used!
do you have small test case to reproduce this bug? i wasn't able to, but
poked around a bit and see:
#Carp.pm:
sub longmess {
{ local $@; require Carp::Heavy; } # XXX fix require to not clear $@?
goto longmess_heavy;
}
and perl.c:call_sv():
PL_eval_root = PL_op; /* Only needed so that goto works right.*/
which leads me to think goto() + call_sv() (which is how mod_perl
invokes handlers) can lead to trouble, we just need to figure out exactly
what is tripping it up. it's not clear from the module changes you made
to bandaid the bug, i'd like to be able to reproduce this and step in with
gdb. i have a feeling it's something to do with AUTOLOAD+eval "" changing
PL_eval_root, but i can only guess at this point.
Re: GET html page - permission denied
On Thu, 25 May 2000, Prasit P wrote: By the way, i can access "http://209.10.98.1/index.html" using internet browser, but not the perl socket. because the browser doesn't include http://x.x.x.x in the http request, unless you are configured to use an http proxy. print $remote "GET http://209.10.98.1/index.html HTTP/1.0\n\n"; change that to "GET /index.html HTTP/1.0\n\n", which is the same as your browser would send.
Re: global variables and reparsing (short reproducible example)
On Fri, 26 May 2000, Marc Lehmann wrote: On Thu, May 25, 2000 at 12:09:09PM -0700, Doug MacEachern [EMAIL PROTECTED] wrote: You can only configure Apache from Perl sections, but you can load all your modules, shared data, etc. from a file pulled in with PerlRequire. actually you can, if a module defines variables in the Apache::ReadConfig:: namespace, they are fed to the apache config gears just as Perl sections are. Erhm, I am doing this right now (the functions I call just implant Location directives etc.. into the caller's package). Now it would be interesting to know wether that works only when called from perl sections or also form perlrequire? (Hmm, I'll just try it out and assume it's supported if it works ;) yes, it's supported with PerlRequire and PerlModule.
Re: global variables and reparsing question (low priority ;)
forget about mod_perl for a moment. yes, true, Perl's built-in require
will not reload a module if it's already in %INC. but that's doesn't mean
a Perl environment cannot un-cache that entry so it will be reloaded.
consider the code below, pretend that loop is a long-lifetime server,
Tk type application, vi or emacs with Perl embedded:
use Module::Reload ();
do {
Module::Reload-check;
require Foo;
} while (STDIN);
Module::Reload checks the mtime of Foo.pm (and all loaded modules) on
disk, if it has changed since the last time it was require'd, it will be
reloaded. this is perfectly valid Perl, the language supports this
feature. i'm quite certain your code be changed to adapt to such an
environment.
Re: does mod_perl with USE_DSO=1 require perl built with -Duseshrplib?
On Fri, 26 May 2000, Benedict Lofstedt wrote: I have a number of apache servers on various hosts, not all of them are to be mod_perl enabled. So, I tried to build apache with mod_perl as a DSO in order to enable mod_perl via the httpd.conf file if needed. I tried building mod_perl-1.24 as a DSO for apache-1.3.14 on my Irix platform. Building went well, I got a libperl.so etc. However, the resulting httpd failed during make test, with a message about not being able to find PL_curpad when loading IO.so - similar to what is described in mod_perl_traps.pod. -Duseshrplib is not required. maybe you have a libperl.a in a place where it shouldn't be, like /usr/local/lib/libperl.a?
Re: mod_perl 1.24 testing keeps failing
On Fri, 26 May 2000, Mark Murphy wrote: I have one more issue with the "make test" for mod_perl. The documentation indicates that SSL doesn't like /dev/null and that SSLDisable is set. Well, after changing /dev/null and making sure SSLDisable is set in the httpd.conf file, I was still getting an error with mod_ssl where did you change /dev/null ? [Thu May 25 19:34:31 2000] [error] mod_ssl: Init: Failed to generate temporary 5 12 bit RSA private key no idea on this one, maybe a permission problem? strace might help: % make start_httpd % strace -f -s1024 -o strace.out -p `cat t/logs/httpd.pid` % make run_tests % make kill_httpd there's probably an open() call in strace.out to generate the tmp key. I had to comment out the LoadModule for libssl in the test httpd.conf file. Once I did that I got results. During the "make test" for mod_perl I received 1 failure. modules/ssi.FAILED before any test output arrived no cause for alarm. the #perl ssi directive is disable when mod_perl is built as a dso, the test should be skipped too, must be a flaw in the test suite.
Re: global variables and reparsing question (low priority ;)
On Fri, 26 May 2000, Marc Lehmann wrote: I know this and I have no problems with that (as I made very clear in my last mail). But when mod_perl requires special programming techniques this does not mean that code not using that techniques is "broken anyway", as dougm said, at least not in perl. It might be "broken code", but then the language is not perl (where the problematic technique is documented to work in perltoot). when i said 'broken', that is shorthand for, you need to change your code so it can deal with being reloaded. which, is valid in the Perl language. As I explained I was getting defensive simply because _not_ all are friends here. I am still defensive because calling somebody else's code broken should not be done so lightly. you shouldn't take offense to what i said, it was not directed at you alone, i've said it plenty of times before you brought it up. just as i've said using 'exit()' is broken, along with any other code that makes assumptions about it's calling environment. What happened, if you go back and read the thread, is that I had a question and had a very hard time explaining what I actually meant (because my initial mails were simply not verbose enough on the problem). Many responses (especially the private ones) were very aggressive, so "we are all friends" is a myth. i didn't see any "aggressive" responses on the list, if mine came across that way, i apoligize, i certainly didn't mean to. i've spent a great deal of time trying to help people on this list over the past 4 years and trying to make mod_perl better at the same time. my responses tend to be short and to the point to optimize my time, i'm a really friendly guy in person :) Since this is my first contact with modperl, however, this just means that I wasn't able to adjust myself to the tone on (and around) the modperl mailinglist.. Next time I will simply ignore most of the responses. i think the tone in general on this list is *very* positive and friendly, much more so than the few other lists i subscribe to. don't let one misunderstanding discourage you, harsh words are very rare here.
Re: Problem compiling mod_perl 1.24 on Solaris 2.6
On Fri, 26 May 2000, Fred Miller wrote: Thank you very much. Sorry for being such a newbie. no need to apologize, this sort of problem isn't normal, if anyone should say sorry, it's sun for their flawed compiler kit. I rebuilt Perl with gcc, and then was able to get a build of Apache with mod_perl. great news.
RE: installation of GTop and Scoreboard
On Tue, 30 May 2000, Alex Algard wrote: Thanks, but installing glibtop only solved the GTop.pm issue. We're still having the same problem with Scoreboard.pm. Below is the output from the Scoreboard.pm installation process. Error: 'Apache' not in typemap in DummyScoreboard.xs, line 122 you need to install mod_perl, a version that is built against the Apache sources, so it installs the apache header files and the mod_perl typemap
Re: Perl 5.6+mod_perl bugs (was Re: Win32 mod_perl binary [update])
On Tue, 30 May 2000, Jeremy Howard wrote:
* Many problems appear running under Apache::DB. In particular,
Apache::Util::escape_uri causes a segfault under Apache::DB in some
circumstances, as does Apache::Request::register_cleanup (when called as
a class rather than an object method)
* Slight changes to code can cause a segfault for no apparent reason.
For instance, under Apache::DB, the following causes a crash (from
Email::Valid)...
$Resolver = new Net::DNS::Resolver unless $@;
...while the following works fine...
if (!$@) {
$Resolver = new Net::DNS::Resolver;
}
the debugger is often tripped up inside mod_perl (inside perl_call_sv i
should say), i've had problems with 5.005_03 too. if you can post tiny
examples that trip up the debugger, i can look into them.
the debugger is another case of 'broken' code, it assumes it will only be
run from the command line with the -d switch (which is why the Apache::DB
wrapper is required). it's certainly worth doing what we need to so it's
happy inside mod_perl.
Re: CGI.pm's -compile/-autoload methods
1. regarding -compile, if the tags are imported into the startup.pl's package or main:: they aren't inhereted by child processes and therefore not adding some memory size to the total child process size, am I right? (well it's shared anyway) doesn't matter if it's shared, it's shared un-needed bloat! i would use CGI::compile() instead of use CGI -compile, as gunther suggested.
Re: Apache::Registry RFE
On Tue, 30 May 2000, Michael Blakeley wrote:
Of course there was an error...
At 9:54 PM -0700 5/30/2000, Michael Blakeley wrote:
$r-log_error($errsv) if $Apache::RegistryYA::AutoLog;
s/RegistryYA/Registry
I'm also having second thoughts about the binary nature of this
thing... I'd forgotten that $errsv might well be a text message like:
Can't locate object method foo via package "Apache" at...
which I'd quite like to see in the log.
So maybe...
$ diff -w Registry.pm.orig Registry.pm
26a27,28
$Apache::Registry::AutoLog ||= 32768;
155c157,160
$r-log_error($errsv);
---
{
local $^W = 0;
$r-log_error($errsv) if $Apache::Registry::AutoLog 0+$errsv
}
This way, setting $Apache::Registry::AutoLog = 300 gives me the
behavior I want (no extra log lines for 302, 304, 500) while still
letting "true" eval errors through. The default value should come
pretty close to the original behavior.
thanks for the patch, but we've stopped adding features to
Apache::Registry. you can implement this with a subclass of
Apache::RegistryNG, something like so:
package My::Registry;
use Apache::RegistryNG ();
@ISA = qw(Apache::RegistryNG);
sub log_error {
my($r, $errsv) = @_;
$r-SUPER::log_error($errsv) if $AutoLog 0+$errsv
}
1;
__END__
PerlHandler My::Registry
Re: Perl Section questions
On Wed, 31 May 2000, Kees Vonk 7249 24549 wrote:
I have two questions about perl sections:
1) Has setting an entry in the %ENV hash in a perl section
the same effect as using a SetEnv (or PerlSetEnv)
no, %ENV is cleared at startup, you need to use the *Env directives for
any you want to stick around.
directive (What btw is the difference between SetEnv and
PerlSetEnv, both seem to effect %ENV in the same way.)
SetEnv doesn't happen until the fixup phase, PerlSetEnv happens asap, so
those variables are available before then, e.g. in PerlAuthenHandler for
$ENV{ORACLE_HOME} + Apache::AuthenDBI
2) If the order of directives in a Location section matters
(see recent discussion on Apache::PerlVINC), does that
mean I cannot use Perl Sections to configure that because
the order of hash keys is unreliable.
you can use:
$PerlConfig .= EOF;
EOF
or
push @PerlConfig, ...;
or
Apache-httpd_conf(...);
to generate config that must have order preserved.
RE: Wierd problem with redirect
On Wed, 31 May 2000, Jeffrey W. Baker wrote: On Tue, 30 May 2000, Jerrad Pierce wrote: I'm running into an odd redirect ptoblem myself, I'm issuing: HTTP/1.1 302 Moved Temporarily\n\r Date: Tue 30 May 2000 18:18:07 GMT\n\r Server: Apache/1.311\n\r Set-Cookie: SESSION_ID=4177a0c9ae2b278decd6038901b28a2a; path=/; expires=Thu, 1-Jan-70 00:20:00 GMT;\n\r Location: /\n\r If you don't follow the HTTP specification, you can't expect the browser to do the right thing. "/" is not a valid URI for a Location. According to RFC 2616, the Location must be an absolute URI: but it is valid in apache, for mod_cgi scripts and mod_perl scripts that have PerlSendHeader On. apache will do an internal redirect if the url is not absolute.
RE: elusive, disappearing notes?
On Wed, 31 May 2000, Geoffrey Young wrote: I've seen this before and always thought to attribute it to mod_dir creating a new request to properly map / to /index.html since any notes set are for the lifetime of the request only, the new request (representing /index.html) would/should have no notes... right. you should be able to always get the same notes table with something like so: my $notes = $r-main ? $r-main-notes : $r-notes;
Re: Apache::PerlVINC again
On Thu, 1 Jun 2000, Kees Vonk 7249 24549 wrote: The following works on Apache/1.3.6 (Unix) mod_perl/1.21 mod_ssl/2.3.5 OpenSSL/0.9.3a But when running on Apache/1.3.9 (Unix) mod_perl/1.21 mod_ssl/2.4.8 OpenSSL/0.9.4, I get the following problem which _appears_ (I am not 100% sure) to be caused by Apache::PerlVINC. I have the following section in my httpd.conf ... The moment I uncomment the PerlVINC lines (or even just the first one) apache fails to start without any error message (STDOUT or logs (LogLevel debug)) or core file. you'll need to try this: Date: Thu, 25 May 2000 12:13:20 -0700 (PDT) From: Doug MacEachern [EMAIL PROTECTED] To: Roberto Bourgonjen [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Re: httpd exits with apache-1.3.12 and mod_perl-1.21 on Redhat 6.2 On Wed, 24 May 2000, Roberto Bourgonjen wrote: Hi all, I am encountering strange problems on redhat 6.2 installations with rpm's apache-1.3.12-2 and mod_perl-1.21-10 (the latest available versions from redhat. I _have_ to use rpm's). I've tried two machines. As soon as load certain modules the server exits immediately, without producing the slightest error message. try this: % gdb httpd (gdb) b exit (gdb) run -X whether it core dumps or exit() is called, post the output of: (gdb) bt
Re: Apache::Registry RFE
Thanks - but RegistryNG causes problems elsewhere in my code.
Apache::File::mtime() doesn't seem to work with RegistryNG. The code:
whoops!! Apache::PerlRun/RegistryNG were written before apache introduced
the ap_update_mtime api function. i've renamed Apache::PerlRun's version
to set_mtime, as it is not supposed to override Apache::update_mtime.
Index: lib/Apache/PerlRun.pm
===
RCS file: /home/cvs/modperl/lib/Apache/PerlRun.pm,v
retrieving revision 1.28
diff -u -r1.28 PerlRun.pm
--- lib/Apache/PerlRun.pm 2000/05/12 07:10:57 1.28
+++ lib/Apache/PerlRun.pm 2000/06/01 21:05:12
@@ -104,7 +104,7 @@
$Apache::Registry-{$package}{'mtime'} = $mtime);
}
-sub update_mtime {
+sub set_mtime {
my($pr, $mtime, $package) = @_;
$mtime ||= $pr-{'mtime'};
$package ||= $pr-{'namespace'};
Index: lib/Apache/RegistryNG.pm
===
RCS file: /home/cvs/modperl/lib/Apache/RegistryNG.pm,v
retrieving revision 1.5
diff -u -r1.5 RegistryNG.pm
--- lib/Apache/RegistryNG.pm1999/06/11 02:50:01 1.5
+++ lib/Apache/RegistryNG.pm2000/06/01 21:05:12
@@ -45,7 +45,7 @@
$pr-sub_wrap;
my $rc = $pr-compile;
return $rc if $rc != OK;
- $pr-update_mtime;
+ $pr-set_mtime;
}
$rc = $pr-run(@_);
Re: custom_response/segfaults
On Thu, 1 Jun 2000, Paul wrote:
After code verifying that the user hasn't already
been registered/approved, I changed the code below
==
if ($url !~ /NewReg[.]cgi$/o) {
$r-custom_response(FORBIDDEN,
"/public/NewReg.cgi");
return FORBIDDEN; # trigger custom_response
}
==
to
==
return OK
if $url =~ m{ # (I removed a few patterns here)
.*NewReg.cgi
}ixo;
$r-headers_out-add('Location' =
"$serverpath/NewReg.cgi");
return MOVED;
==
and my segfaults seem to have stopped killing my
server child provcesses.
Did I use custom_response incorrectly?
you're using it the right way. which Perl*Handler are you calling it
from? can you get a stacktrace? (see SUPPORT doc)
Re: Apache children hanging
On Thu, 1 Jun 2000, Gustavo Duarte wrote:
there to see if it stops the problem (the code isn't too clean - lots of
global variables, not written under strict, etc, but "it works").
looks like a global variable is exactly what your problem is. somebody is
creating an Apache::SubRequest object (via $r-lookup_{file,uri}, and it's
not going out of scope until the child exits. in this case, when
Apache::SubRequest::DESTROY is called, it calls destroy_sub_req() on a
pool that's already been cleared.
#0 0x80a7407 in free_blocks ()
#1 0x80a7660 in ap_clear_pool ()
#2 0x80a76a1 in ap_destroy_pool ()
#3 0x80be71a in ap_destroy_sub_req ()
#4 0x8070d8a in XS_Apache__SubRequest_DESTROY ()
...
#12 0x40077fa5 in perl_destruct () at perl.c:1008
#13 0x80635a3 in perl_shutdown ()
#14 0x80645c5 in perl_child_exit ()
Re: Apache children hanging
you can find out which line of Perl code is triggering a spin, by attaching to the process with gdb; % gdb httpd $pid_of_spinning_process % source modperl_x.xx/.gdbinit % curinfo should show you the filename:line_number where Perl is stuck.
Re: Apache children hanging
% gdb httpd $pid_of_spinning_process % source modperl_x.xx/.gdbinit % curinfo oops, that should be: % gdb httpd $pid_of_spinning_process (gdb) source modperl_x.xx/.gdbinit (gdb) curinfo
Re: problem with IO::Select under Apache::Registry (long)
On Thu, 1 Jun 2000, tim fulcher wrote: 2000] Msg.pm: Can't call method "new" without a package or object reference at /usr/borg/lib/perl5/5.00503/Msg.pm line 11. ... mod_perl 1.21 try upgrading to 1.24. a fix related to the Perl stack pointer in 1.23 might be the cure for this.
Re: Apache children hanging (not exiting)
On Thu, 1 Jun 2000, Jay Jacobs wrote: With that previous thread of Apache children hanging up the server it made me think of an issue I see quite frequently in development... When I stop the mod_perl server, it won't exit properly (or fast) : [warn] child process 8530 still did not exit, sending a SIGTERM (multiplied by number of processes) I've seen this on servers running really sloppy code as well as really tight code (but a lot of it). Eventually the children do die off, but it takes about 15 seconds... from mod_perl.pod: =item PERL_DESTRUCT_LEVEL With Apache versions 1.3.0 and higher, mod_perl will call the perl_destruct() Perl API function during the child exit phase. This will cause proper execution of BEND blocks found during server startup along with invoking the BDESTROY method on global objects who are still alive. It is possible that this operation may take a long time to finish, causing problems during a restart. If your code does not contain and BEND blocks or BDESTROY methods which need to be run during child server shutdown, this destruction can be avoided by setting the IPERL_DESTRUCT_LEVEL environment variable to C-1.
Re: err_headers_out Q
On Fri, 2 Jun 2000, Geoffrey Young wrote:
hi all...
this simple script:
#!/usr/bin/perl
my $r = shift;
$r-err_headers_out-add('Set-Cookie' = "name=error");
warn "pre headers_out: " . $r-headers_out-get('Set-Cookie');
$r-send_http_header('text/plain');
warn "post headers_out: " . $r-headers_out-get('Set-Cookie');
print "done";
yields:
pre headers_out: at /usr/local/apache/perl-bin/err.cgi line 7.
post headers_out: name=error at /usr/local/apache/perl-bin/err.cgi line 9.
and sets the cookie...
I was initially trying to create a PerlInitHandler to put a cookie in
err_headers_out, which I would expect to be set only if other handlers down
the line error out, but it was being set every request.
am I misunderstanding err_headers_out, or is send_http_header misbehaving?
see http_protocol.c:send_http_header():
if (!ap_is_empty_table(r-err_headers_out))
r-headers_out = ap_overlay_tables(r-pool, r-err_headers_out,
r-headers_out);
Re: use DBI () (and modules in same die) dies in startup.pl
On Fri, 2 Jun 2000, Michael Todd Glazier wrote: Hey all! I'm having a really weird problem with mod_perl where is dies loading modules from a certain dir in startup.pl I'm running Red Hat Linux 6.2 with: Embedded Perl version 5.00503 for Apache/1.3.12 (Unix) (Red Hat/Linux) mod_perl/1.21 try mod_perl/1.24
Re: Segment fault in Perl_pp_leavetry
On Tue, 6 Jun 2000, Mike McLagan wrote: Hello, I am having the above segfault using mod_perl 1.23 and mod_perl 1.24 on a RedHat 6.2 system with Perl 5.00503. The Apache daemon was compiled with max DSO and included the mod_ssl patches, etc as shown below. mod_perl is compiled with -DEAPI per it's request. If I operate without mod_auth_mysql, the server is fine. If I operate without mod_perl, the server is fine but my perl programs don't work. The code for mod_auth_mysql hasn't changed in over a year or more so I am inclined to believe that it's not the source of the problem. [root #] gdb httpd (gdb) set args -X (gdb) run [notice] Apache/1.3.12 (Unix) AuthMySQL/2.20 mod_ssl/2.6.2 OpenSSL/0.9.5 mod_perl/1.24 configured -- resuming normal operations Program received signal SIGSEGV, Segmentation fault. 0x40286b78 in Perl_pp_leavetry () from /usr/lib/apache/mod_perl.so (gdb) bt #0 0x40286b78 in Perl_pp_leavetry () from /usr/lib/apache/mod_perl.so #1 0x40204238 in ?? () from /usr/lib/apache/mod_perl.so #2 0x78756e69 in ?? () Cannot access memory at address 0x6c2e6264 (gdb) try this: (gdb) source mod_perl-x.xx/.gdbinit (gdb) curinfo hopefully that will print the filename:line of the code Perl was running here. maybe that will shed some light. do you have these same troubles if mod_perl is linked static?
Re: $r-register_cleanup limits?
On Tue, 6 Jun 2000, Jim Woodgate wrote:
In a module I'm using register_cleanup so the client doesn't need to
wait for me to do a bunch of work. It basically does this:
foreach (@images) {
unless (-f $thumb{$_}) {
create_thumb($_);
$r-register_cleanup(sub {create_more_sizes($_, ...)});
}
}
there's no limit the number of cleanups you can register, but i would
still push the sub {}'s into an array and register a single cleanup to
iterate over them.
create_more_sizes will create various additional sizes to scale down a
large picture.
This seems to work really well unless there is a large set of images,
then the cleanup handler doesn't get all the way through. I don't see
any warnings/errors. (And unfortunately since the thumbnail is
created the next time someone visits create_more_sizes won't get
called unless I do explicit checks, which would cause me to actually
read the images and I was hoping to avoid that)
Anyway I'm not sure if I'm hitting a limit on the amount of time it
is taking or if I'm just registering too many cleanups.
I was thinking of $r-reset_timeout() as the first line of
create_more_size(), but thought I would check with the list first as I
don't fully understand the ramifications.
i don't think $r-*_timeout will work properly in a cleanup, but alarm +
eval {} should be fine. if you want to see where it's stuck, try this:
% gdb httpd pid of spinning process
(gdb) where
(gdb) source mod_perl-x.xx/.gdbinit
(gdb) curinfo
Re: Apache hanging when it reaches limit of process limit
On Tue, 6 Jun 2000, Tom Lancaster wrote: Hi, I've got this strange behavior in a production site that until a recent upgrade never showed this kind of thing: I've set maxclients to 50, maxrequestsperchild 1. What happens is that the server runs fine, is fast, etc, but the number of apache processes climbs gradually until it reaches ~maxclients, then will no longer serve pages. I thought this was due to children not exiting, but some of them apparently do, as the number of processes rises and falls on its way to the top. What is Apache supposed to do when you set maxrequestsperchild to 1? I'd have thought each process would exit immediatley after serving something. I'm inclined to think there's something in my code that's hanging, but I read that the symptom of that is processes consuming large amounts of CPU - they're not, and memory usage is normal, too (~10M). Another symptom: sometimes when the processes are nearing the top, they'll start haging, but one by one; if I hit stop on a non-responsive request, then re-try, it serves fine. I'm using the debian package of modperl 1.21 statically linked with apache 1.3.9, and HTML::Embperl 1.2.1 ( I think). i suggest upgrading to 1.24. i also suggest setting maxrequestsperchild higher than 1. if you do have httpds hanging, this might shed some light: % gdb httpd pid of spinning process (gdb) where (gdb) source mod_perl-x.xx/.gdbinit (gdb) curinfo
Re: Apache hanging when it reaches limit of process limit
On Tue, 6 Jun 2000, Tom Lancaster wrote: Here's the output of gdb: ( now what does this mean?) ... Breakpoint 1, 0x400ddd35 in exit () from /lib/libc.so.6 (gdb) bt #0 0x400ddd35 in exit () from /lib/libc.so.6 #1 0x80851e1 in ap_start_restart () #2 0x8085454 in ap_start_restart () #3 0x80862d7 in ap_child_terminate () #4 0x8086a4d in main () #5 0x400d5a42 in __libc_start_main () from /lib/libc.so.6 (gdb) the exit() makes sense, since you have maxrequestsperchild set to 1, but the stacktrace should look more like this: (gdb) where #0 exit (status=0) at exit.c:40 #1 0x80cf0eb in clean_child_exit (code=0) at http_main.c:493 #2 0x80d1e83 in child_main (child_num_arg=0) at http_main.c:3893 #3 0x80d23dc in make_child (s=0x821dbe4, slot=0, now=960572421) at http_main.c:4264 #4 0x80d2537 in startup_children (number_to_start=5) at http_main.c:4346 #5 0x80d2b54 in standalone_main (argc=6, argv=0xb624) at http_main.c:4634 #6 0x80d32d3 in main (argc=6, argv=0xb624) at http_main.c:4961 are you calling $r-child_terminate somewhere? that's not actually called anywhere in the apache source, it's just an api for modules.
Re: Apache dumping core in mod_perl's 'make test'
On Tue, 6 Jun 2000, Stas Bekman wrote: Please! Keep the questions on the list!!! thank you! Thought the aforementioned procedure might be useful explaining my current trouble. Perl 5.5.3, Apache 1.3.12, mod_perl 1.24 -- no other add-ons to Apache... OS is Linux (kernel 2.2.10). Any hints? I think I've seen this behavior when I had DProf enabled (the same enviroment). Turn it off. I've ported this report myself clueless about the reason, but apparently it wasn't answered :( #0 0x40175c7f in _IO_fflush (fp=0x4020d480) at iofflush.c:41 what's the output of: (gdb) print *fp i'm quite sure _fileno will be 2 (stderr), which something may have botched, what i don't know. strace-ing to see fiddlings with fd 2 might shed some light.
