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: 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: 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: CGI::Delete for Apache::Request
say, rfc's are good for something after all ;) ok, form_data() it is!
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: Apache::DBI-connect_on_init in BEGIN?
On Sun, 14 May 2000, svante [iso-8859-1] sörmark wrote:
hi all,
what i'd like to do is "pre-initialize" my DBI connections from whithin
my PerlHandler's BEGIN block.
something like this:
BEGIN {
if ( Apache-dir_config('CONNECT_ON_INIT') {
Apache::DBI-connect_on_init(Apache-dir_config('DBI_INFO');
}
}
connect_on_init was written to be a PerlChildInitHandler, it doesn't make
sense to use it anywhere else.
RE: CGI::Delete for Apache::Request
+=item parms thanks. the reason i've been holding off though, was because i wanted to rename parms() to be something a little more different from param(). i've asked for suggestions a few times, got any? :) p.s. from cvs Changes: Apache::Table-unset can now be called with an array reference
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: Zombie processes under mod_perl
On Mon, 15 May 2000, Leonardo Madrigal wrote:
Hi everyone!
Im working on some scripts that run under mod_perl via
Apache::Registry, on the latest stable versions of mod_perl and apache
under FreeBSD 3.3-stable.
This scripts make authentication to cybercash using the api that they
provide.
The problem is that in the API are 2 programs (binarys made in C) that
are called, if i ran the scripts under Apache::Registry, when the perl
scripts are done and the httpd proccess end, the 2 programs now are in
zombie state, for every request.
If i dont use mod_perl the scripts are ok. No zombie proccesses.
This is the code from cybercash that runs the first one:
MCKencrypt="/usr/local/bin/mckencrypt";
unless (open2(\*CIPHER, \*PLAINTEXT, $MCKencrypt)) {
return($E_EncryptFailed, MCKGetErrorMessage($E_EncryptFailed));
}
As you can see, they use open() and my perl was not compiled with sfio
support.
i don't see you call close() on CIPHER and PLAINTEXT, which will
trigger a zombie since those filehandles are global. if you at least
local-ize them, or use a lexical glob (like Symbol::gensym or 'open my
$fh, ...' w/ 5.6.0), Perl will take care to cleanup for you.
Re: Apache::DBI-connect_on_init in BEGIN?
the problem is i can't seem to find a way to get configration variables from httpd.conf inside a BEGIN or a PerlChildInitHandler. i set the variables with PerlSetVar inside Location ... sections. use Apache-server-dir_config as eric already suggested to you. you'll have to move the PerlSetVar outside of Location ... though. you can use PerlSetEnv too.
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: without Apache::Registry, redefined subs still?
On Tue, 9 May 2000, w trillich wrote: redefined subs with perlrun? it's just a warning. but, that warning should go away if you use the cvs version of Apache::PerlRun
Re: Segmentation fault (11) with mod_perl 1.23...
On Fri, 12 May 2000, Mark Haviland wrote: Hey all... I just upgraded my box to redhat 6.2.2 and compiled Apache 1.3.12 with mod_perl (1.23) as a DSO (outside the Apache tree using apxs). Now, modules that use to work are suddenly causing seg faults. The one in particular that doens't seem to jive with mod_perl is Sybase::CTlib. Has anybody else seen this problem ? what versions of things did you upgrade from? where you using dso with the older versions? unload_xs_so: 0x8396fc0 hmm, i wonder if the dso "fix" broke things for you, what happens if you comment out this line of mod_perl.c: unload_xs_so(librefs);
Re: works on linux, doesn't work on sun.
Location / SetHandler perl-script PerlSendHeader on PerlHandler Mf7 Options +ExecCGI strange that would fix things, unless your Mf7 module is testing for $r-allow_options OPT_EXECCGI mod_perl never checks that bit, it's up to modules, e.g. Apache::Registry make that check.
Re: Problem with @INC
On Sat, 13 May 2000, Robert Nice wrote: use lib '../site_perl'; it's been explained, 'use lib' happens at compile time (once per-script) and @INC is reset to whatever it was startup time after each request. the simple solution for you, which i didn't see mentioned, is to modify @INC at runtime, e.g. unshift @INC, '../site_perl';
Re: Undefined DESTROY() in error_log
On Sat, 13 May 2000, Kenneth Lee wrote: I see this error message in my error_log, [Sat May 13 13:06:38 2000] [error](in cleanup) Undefined method HTML::FastTemplate::DESTROY at /usr/lib/perl5/site_perl/5.6.0/i686-linux/Apache/Registry.pm line 144 Does it mean that I have to add a dummy DESTORY() in my package? Is there any docs discussing this already? sounds like a broken AUTOLOAD function. "Undefined method" is not an error message from Perl, where is that coming from? in any case, a dummy DESTROY should bandaid just fine.
Re: Virtual servers mixing up required scripts
give me some insight into this problem: - Is this a known bug, or an unavoidable by-product of the way mod_perl works? - Is it related to the fact I'm using Apache::Registry? Would switching to the native Apache API fix it? - Is it related to the fact I'm using "require", with ".pl" files? Would switching to "use" (with .pm modules) fix it? no. search the archives and/or guide for Apache::PerlVINC
Re: Can't use Apache::exit() in command-line scripts
On Fri, 5 May 2000, Bill Moseley wrote: At 12:05 AM 05/04/00 -0700, Doug MacEachern wrote: you're calling exit in a module? shame on you. if you call exit() from a script that is compiled by Apache::Registry (not include *.pm), exit() will be overridden for you to call Apache::exit, no changes needed. if you really want to call it in a module, which you really don't, do you? I'm a bit confused. When you say "module" you mean a module use'd by the Apache::Registry script? Because exit() is overridden in those modules, too, no? I can call exit() fine in a module, but if I say CORE::exit() the child is killed off. yeah, i forgot, mod_perl uses CORE::GLOBAL:: to override it everywhere.
Re: Newbie Question -
On Sat, 6 May 2000, Gunther Birznieks wrote: At 06:56 PM 5/5/00 -0400, Jim Winstead wrote: On May 05, Adi wrote: You can still use CGI.pm from within mod_perl (and you should). There is nothing better at handling data passed from a browser via HTTP POST and/or GET. If you currently use CGI.pm, I think you'll find that a lot of your current code can simply be cut-and-pasted into a mod_perl setup. Well, arguably Apache::Request is better at handling data passed from a browser via HTTP POST and/or GET in a mod_perl environment. And it has the advantage that is entirely focused on request handling, and doesn't have any of the HTML generation cruft like CGI.pm. The "HTML Generation cruft" is optional "cruft" and doesn't have to be compiled in. not compiled, but the all the code lives in a BIG hash table for CGI.pm to autoload from. the export lists take up alot of space too. regardless if you're using html routines or not.
Re: Re: mod_perl-1.99_01-dev
On Sat, 6 May 2000, Greg Cope wrote:
: But you will be not able to tune the two types of the threads to have
: different Apache parameters (MaxRequests and others) so I'm not sure
you
: will get rid of the dual setup, unless these will be taken care of by
: mod_perl.
:
: well, there is a PerlInterpMaxRequests parameter in 1.99_01-dev, which
: knocks off the Perl clone after x number of requests. in addition, the
: pool of interpreters are pulled and putback from the head of the list, so
: you are getting re-used allocations (e.g. padlists aka lexicals). that
: is, say you configured PerlInterpStart to 10, but average no more than 5
: concurrent requests. you have 5 clones with allocated padlists, and 5
: which are much smaller (but ready for conncurrent requests 5). this is
: unlike 1.3 where you have 10 children, chances are high each of them will
: endup will allocated padlists, as there's no control over which child
: handles a request.
:
: i'm not saying 2.0 will rid the need for a dual setup, but the Perl side
: is looking a whole lot smaller (er, less fat) at this point.
If using the threaded model can we not configure say:
10 apache children (fixed)
X number of threads
Y PerlInterpStart
yes.
This would (if my understanding is correct) result in a request arriving and
being :
- either be dealt with by a normal apache thread if not a mod_perl
handler - i.e {html|gif|png|jpeg}
- or a by a light apache thread that calls a perlInterpreter from the pool
to handle the mod_perl handler
there's no 'normal apache thread' or 'light apache thread', just 'apache
thread'. all requests are handled the sameway thread-wise. the only
difference for Perl requests is that an interpreter is plucked from the
pool and callbacks into that Perl runtime are made.
Combine with a garbage collector thread this would be excellent as it would
seriously reduce memory consumption (one of mod_perl's present weaknesses)
indeed.
Re: CGI::Delete for Apache::Request
On Sat, 6 May 2000, Michael Blakeley wrote:
I've been migrating some code off of the ENV-dependent methods in
CGI.pm, so I can turn of PerlSetupEnv. Anyway, I couldn't find an
Apache::Request method that had the functionality of CGI::Delete.
Since I use Delete extensively, I coded a replacement based on the
param() prototype in Apache::Request. This may be useful to other
programmer porting CGI.pm code.
# for compatibility with CGI::Delete - call with $apr-Delete("foo")
sub Delete {
my $self = shift;
my $tab = $self-parms;
for (@_) {
$tab-unset($_);
}
} # end sub Delete
Trivial, once you know how. But maybe worth including in a future rev
of Apache::Request? Or at least documenting? I spent some time just
finding "unset".
i would like to document the $self-parms table, and point to the
Apache::Table docs.
It'd be even better if unset() would take a list argument, of course
that can be arranged :) i would prefer this, rather than adding the
Delete method to Apache::Request.
Re: apache1.3.12, modperl1.23, perl5.6, ApacheJServ1.1, OpenSSL0.9.4, modssl
have you tried this patch? see threads on largefile support for details.
--- Makefile.PL 2000/04/21 19:37:45 1.159
+++ Makefile.PL 2000/04/27 22:45:30 1.160
@@ -186,7 +186,7 @@
$PERL_DEBUG = "";
$PERL_DESTRUCT_LEVEL = "";
$PERL_STATIC_EXTS = "";
-$PERL_EXTRA_CFLAGS = "";
+$PERL_EXTRA_CFLAGS = $] = 5.006 ? $Config{ccflags} : "";
$SSLCacheServerPort = 8539;
$SSL_BASE = "";
$Port = $ENV{HTTP_PORT} || 8529;
Re: make test fails, httpd fails to start
On Mon, 8 May 2000, Stas Bekman wrote: httpd fails to start because of the following. will write error_log to: t/logs/error_log Syntax error on line 3 of /tmp/mod_perl-1.23/t/conf/httpd.conf: Invalid command '=pod', perhaps mis-spelled or defined by a module not included in the server configuration Yeah, how about: server failed to start! (please examine t/logs/error_log) at t/TEST line but he already gave all the info we need above. steve, the httpd being used to run the tests does not have mod_perl configured. which means there's a flaw in the steps you took to configure/build. try INSTALL.simple or the appropriate section of the guide.
Re: how to get Devel::Symdump working with mod_perl code?
On Tue, 9 May 2000, Tom Roche wrote: despite the fact that Symbol.pm is in c:/Perls/ActivePerl522/site/lib/Apache, which is in @INC. Which returns me to the original problem: ok, most Apache:: modules that have xs code need to run inside httpd to work properly. you'll notice that most have this line: __PACKAGE__-mod_perl::boot($VERSION); mod_perl::boot will not try to bootstrap the xs code unless you're running inside httpd, so everybody is happy. Apache::Symbol and Apache::Leak are the two exceptions, they should run outside of httpd. however, i'm guessing your ActivePerl was not able to build Apache::Symbol for some reason. ActivePerl isn't happy with mod_perl at all last i checked.
Re: Source Code Shows Up in IE But Not Netscape
On Wed, 10 May 2000, Bri Carey wrote: I realize that this is not an ePerl forum, but since ePerl runs as part of mod_perl, I thought it couldn't hurt to at least ask here. I must be missing something obvious. I've installed Apache::ePerl. I've configured httpd.conf according to the instructions: Files ~ "/usr/local/apache/htdocs/.+\.iphtml$" Options +ExecCGI SetHandler perl-script PerlHandler Apache::ePerl /Files When I display an .iphtml page in Netscape, everything seems to be fine. When I display it in IE (4.72), I get a plain text output of the source code, including html tags. Why this discrepancy? sounds like an http headers problem. what do you see with a telnet request? probably not a complete set of httpd headers, try adding: PerlSendHeader On in your config
Re: About $r-connection-user
On Fri, 12 May 2000, Kenneth Lee wrote:
hi modperlers,
If I call $r-connection-user(something) in a PerlAccessHandler,
besides I can see that user name in the access log, will $ENV{HTTP_USER}
be set by Apache or the subsequent handlers, like the default auth and
authz modules?
yep.
Re: [Fwd: [apache-users] Core with x86 solaris modperl]
i'm going to release 1.24 asap to stop this madness. looks like another
case of the 5.6.0 largefile support bug, which the patch below will fix.
for apxs, you'll need to build apache like so:
CFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" \
./configure \
...
--- Makefile.PL 2000/04/21 19:37:45 1.159
+++ Makefile.PL 2000/04/27 22:45:30 1.160
@@ -186,7 +186,7 @@
$PERL_DEBUG = "";
$PERL_DESTRUCT_LEVEL = "";
$PERL_STATIC_EXTS = "";
-$PERL_EXTRA_CFLAGS = "";
+$PERL_EXTRA_CFLAGS = $] = 5.006 ? $Config{ccflags} : "";
$SSLCacheServerPort = 8539;
$SSL_BASE = "";
$Port = $ENV{HTTP_PORT} || 8529;
Re: Newbie Question -
not compiled, but the all the code lives in a BIG hash table for CGI.pm to autoload from. the export lists take up alot of space too. regardless if you're using html routines or not. As I have replied to FEITO Nazareno today, this happens only if you precompile CGI.pm's functions at the server startup. I've used B::Terse in /perl-status to check that. Refer to the post with subject "[iso-8859-1] Whats better?program with C" for a complete showcase. If you don't precompile them, only the minumum set of functions will be inherited, so it's possible to exclude the html generation functions. re-read what i said, i'm talking about variables in CGI.pm like %EXPORT_TAGS, %SUBS, etc.
Re: PerlSetVar revisited
Oh, the patch... I've missed this detail, sorry. I understand that it'll enter the soon to be released 1.24, right? not sure if it'll be in 1.24 yet.
Re: [Fwd: [apache-users] Core with x86 solaris modperl]
Did this. Recompiled Apache, modperl, jserv. Same results. :-( what if you use Perl 5.005_03? or 5.006 Configure-d with -Uuselargefiles?
Re: PerlHandler stopped working???
On Tue, 25 Apr 2000, Matt Sergeant wrote:
I do now - just uploaded a new version. It's still not correct though - a
proper fix would have to pull SetHandler out of mod_mime altogether, I
guess. For example, say your config contains:
oh yeah, i forgot, you can call mod_mime's fixup directly too:
use Apache::Module ();
my $rc = Apache::Module-top_module-find("mod_mime")-type_checker-($r);
that digs the type_checker function pointer out of the mod_mime module
structure and returns a reference to an anonymous xsub, which calls that
function. neato, eh?
Re: Problem compiling mod_perl 1.23 on Solaris 2.4
On Thu, 27 Apr 2000, Steve Hay wrote: Steve Hay wrote: I'm having a problem compiling mod_perl 1.23 (with Apache 1.3.12 / Perl 5.6.0) as a DSO using APXS on Solaris 2.4. In case anyone is interested... I've solved my own problem (just as well, really). If I re-compile everything with the -Xa compiler flag then it all works out fine. what does -Xa mean? gcc or ld flag? i don't see anything in the gcc manpage, 2.6 ld manpage says: Options No Longer Supported The following SunOS 4.x.y options do not have any replace- ment in this release: -B nosymbolic (this is now the default if -B symbolic is not used), -d, -dc, and -dp, (these are now the default; see -b above to override the default), -M, -S, -t, -x, -X, and -ysym. maybe that means -Xa is on by default in newer solaris?
Re: Modperl/Apache deficiencies... Memory usage.
On Thu, 4 May 2000 [EMAIL PROTECTED] wrote:
Sounds like a good plan. The first piece to put together is the
script that can register callbacks, and iterate through the perl
threads. Do we have a devel version that's got the mip-avail type
stuff together, or is this something that will be coming together in
the next few weeks?
it's in there now.
Okay so this is a module that would be loaded via
httpd.conf so that the thread can be spun off, and it can begin
analyzing. It should have some parameters so that it doesn't suck up
too much CPU time, like sleep n seconds between jumping to the next
apache embedded interpreter thread, blah, blah. Are we going to dump
this info to perlmemorylogs? (Configurable to some location, etc) Or
integrate it with some sort of online status program?
mod_perl_status :) Or both..., hehe, well, of course that's all
later, first piece is to get the iterator built that registers
callbacks. As an aside, I think the callback thing was a really good
idea on your part, that way you can analyze how much memory your
programs are using and whether you need to re-think your design
strategy or implement a cleaner. Any cleaner, a real aggresive one,
or a really kick back one. In any event, I just wanted to mention
that this was a really good idea of yours (the callbacks).
assuming your moving forward with this (making you a hero :), you should
be able to put the majority of it together without looking at the
mod_perl-2.0 source first. the only thing you need to keep in mind is
that the c functions need to accept a PerlInterpreter argument with
-Dusethreads Perls. Perl has some macros to deal with this "implicit
context", which would look something like so:
void symbol_table_walk(pTHX_ char *package, int recurse, ...)
testing with a vanilla Perl, you would call that like so:
symbol_table_walk(aTHX_ "main", TRUE, ...);
once it's integrated into mod_perl, something like so:
{
#ifdef USE_ITHREADS;
pTHX;
modperl_interp_t *interp = modperl_interp_get(...);
aTHX = interp-perl;
#endif
symbol_table_walk(aTHX_ "main", TRUE, ...);
...
}
that PerlInterpreter structure is used when macros such as:
gv_fetchpv("main", FALSE);
translate into:
Perl_gv_fetchpv(my_perl, "main", FALSE);
Re: PerlAddVar ?
On Thu, 4 May 2000, Matt Sergeant wrote:
How do you get at $r in a directive handler?
other way around, you get at directive handler config from a handler,
which has been passed $r, e.g.:
sub handler {
my $r = shift;
my $cfg = Apache::ModuleConfig-get($r, __PACKAGE__);
$cfg would contain the data stashed by the directive handler.
Anyhow, in the end I went for first class configuration directives, so now
with AxKit you can go:
AddStyleMap text/xsl Apache::AxKit::Language::XSLT
AddStyleMap application/x-xpathscript Apache::AxKit::Language::XPathScript
Very cool - I was amazed it worked first time!
:)
Re: Why does $r-print() dereference its arguments?
On Thu, 4 May 2000, Jeffrey W. Baker wrote:
Not strictly for debugging, but for introspection. I was toying with
a module that pokes around inside the perlguts of a running mod_perl
server and makes some nice displays out of them. Nothing for
production/money mind you, just amusement.
i did have reservations when adding the stunt, but i figured the chances
of somebody printing a $reference on purpose, which was not interpolated
in another string already were pretty slim. seems you're the first to
notice in the two years since the "feature" was added :)
btw, just to be clear, $strings passed to $r-print() are not copied, they
are passed by reference, just like any argument to a subroutine. but
most subroutines copy the arguments into their own variables, e.g.:
sub foo {
my ($header, $body, $footer) = @_;
so the idea was that you could pass around references to strings, which
end up being passed to $r-print, without having to worry about
dereferencing.
Here is a patch I made against the documentation in Apache.pm. Actually,
I had to attach it because it was wrapping.
thanks!
Re: how to get Devel::Symdump working with mod_perl code?
On Thu, 4 May 2000, Tom Roche wrote:
I'm trying to use Devel::Symdump to document code, but Perl
is choking when it hits (what appears to me to be) autoloadable
stuff. I'd like to know how to invoke (or patch, or whatever) Perl in
such a way so as to ignore such problems (or perhaps merely warn/carp
about them), or how to run Devel::Symdump under Apache.
Unfortunately Loader, or rather Perl, is having a problem with
Apache::DBI.pm. The first source file require's OK. The second source
file, GetDBs.pm, use's Apache::DBI(), line 202 of which is
) if ($INC{'Apache.pm'} and Apache-module('Apache::Status'));
that's because Apache::module is only defined when you're running inside
httpd. that line should be something like:
if ($INC{'Apache.pm'} and $ENV{MOD_PERL} and Apache-module('Apache::Status'));
to work inside and outside httpd.
Re: apxs and first class configuration
On Fri, 5 May 2000, Stas Bekman wrote: On Fri, 5 May 2000, Matt Sergeant wrote: When building first class configuration directives, you run Makefile.PL and it says: which: no apxs in (/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin) apxs:Error: Sorry, no DSO support for Apache available apxs:Error: under your platform. Make sure the Apache apxs:Error: module mod_so is compiled into your server apxs:Error: binary `/usr/local/apache/bin/httpd'. But it compiles correctly anyhow. Is this just a check to make sure you have mod_so compiled in? It's a warning. Corrected in the CVS version. -- check out the archives and the Changes file. It's harmless. the correction is part of 1.23 too.
Re: [Q ]Differences between RequestNotes and Request ?
On Fri, 5 May 2000, Thierry-Michel Barral wrote: I have another question, no connection from the previous one: I believe using open FH "tweety.conf"; is in fact a call to the shell. Right ? no! but open FH, "cal|"; would result in a fork/subprocess. see the perldocs, this is not any different under mod_perl. So, in mod_perl, I prefer not to call the shell, so is $fh= new IO::File($filename, "r"); a better solution ? no! that calls the builtin open() underneath, so it's no different in the end, other than the extra layers to get there.
Re: Newbie Question -
On Fri, 5 May 2000, Pierre J. Nicolas wrote:
Good Morning,
I just started using mod_perl, I'm still using the CGI.pm module, but I
plan
to convert. I've loaded the Apache::Registry and I'm experiencing a
strange
problem.
I have this snippet:
print "Content-Type: text/html\n\n";
print_template(file_handle, *file_handle_ref) {
open file_handle()
while (file_handle()) {
manipulate current_line
print file_handle_ref
current_line
}
}
where "*file_handle_ref" could be a reference to STDOUT,
this snippet worked fine, but now it stopped working, instead
I get the message "The document contained no data"
are you saying you re-open STDOUT? if so, you break the tie to the
browser. but, i don't understand the code you've posted, if you have a
tiny example that we can actually run, we should be able to see the
problem.
RE: Newbie Question -
mod_perl overrides the perl print() function - print()ing to STDOUT explititly will not work. just use print() if you can... sure it will, print STDOUT "hi"; and print "hi"; are the same thing, provided STDOUT is the currently selected output filehandle, which it is by default.
Re: newbie problem..
On Fri, 5 May 2000, Kiran Banoor wrote:
hi,
I have written a handler for controlling access control on the basis of
domain/ip address so that i can restrict the users on the limit of sessions
from a perticular domain name.And i placed my handler in .htaccess file.
The problem is when request is made by the client for a perticular file and
it goes to my handler Gatekeeper.pm were if the requested file is having any
ssis it takes as a seperate request so i don't know wether it is write or
not and when i send the file by using send_fd(filehandle)it just displays
the contents of the document but not the ssis.
Another problem is when i set the cookie in the header and use the
send_fd(filehandle)to send the file back it will not work but if i use
print() it works i don't know why ..
i don't see why print() would end up with different results than
send_fd(). sounds like what you really want is
$r-lookup_uri('/foo.ssi')-run
Re: Redirecting Problem --- Please look at this patiently.
On Fri, 5 May 2000, sadhanandham balaraman wrote: Hi Gurus, I'm facing a typical problem in Apache web server. The problem is that I want to call a perl script whenever a request is made to the server, and that script should be able to change the URI and submit to the server back. The thing I got from the net is that adding PerlscriptTransHandler directive will call a perl script, whenever request is made. The problem with this is that it disables Alias and ScriptAlias directives, so my other perl scripts won't run. if your PerlTransHandler returns OK, then the mod_alias translate handler is skipped. just change the uri in your TransHandler and return DECLINED to let mod_alias do it's thing. The other thing is redirecting any request using RewriteRule. I used this to redirect any request to my perl script which again redirects to another document which is in same server by 'Location' header. The problem is that it goes to endless recursive request loop. So how to call a perl script or redirect the request to the SAME web server. $r-internal_redirect should work. we'd need a tiny example that reproduces the recursion problem to help with that.
Re: PerlHandler stopped working???
On Fri, 5 May 2000, Matt Sergeant wrote: Really really freaky. However I assume you saw the post - I solved it by doing push_handler() with a Fixup and returning DECLINED. That way mod_mime gets to do its stuff, and my content_type still gets set regardless. yeah, i know, it's cinco de mayo, so take that code with a tequilla shot and some grains of salt ;)
Re: PerlAddVar ?
Cool! I guess it's a non-documented feature :) it's documented in ch9 of the eagle book :)
Re: Apache::Registry and clearing package name space
On Mon, 1 May 2000, Richard Chen wrote:
Hello,
I am having a problem clearing variables and aliases
in a temporary package name space. The source of the problem
is in making legend cgi scripts work under Apache::Registry.
But the problem can be isolated and shown by the following
demo program:
$ cat foo.cgi
#!/usr/bin/perl -w
use strict;
use Symbol qw(delete_package);
print "Content-type: text/plain\n\n";
%Q::userdata=();
$Q::userdata{first_name}='first_name';
$Q::userdata{last_name}='last_name';
*Q::hello=\hello;
print "here is the symbol table\n";
while (my($k,$v)=each %Q::) {
print "$k = $v\n";
}
delete_package('Q');
sub hello {
print "hi\n";
}
The first time it runs, it yields:
here is the symbol table
userdata = *Q::userdata
hello = *Q::hello
But there after, modperl shows emtpy symbol table.
the problem is that Perl creates symbol table references at compile time,
Symbol::delete_package() wipes those references out of existence.
try using Apache::PerlRun-flush_namespace('Q'), which clears just
the values, and leaves the references in tact.
Re: mod_perl httpd binary suddenly stops working
On Mon, 1 May 2000, James Olsen wrote: Hello, I have a mod_perl/apache binary and configuration file that I've been using successfully since October of last year. Last week I ran out of disk space (and might possibly have had the server flake out over the CPU overheating). Everything appears to be running smoothly now with a larger fan and more disk space, except the original httpd binary and config file I had refuse to start - it simply exits without any error messages or log entries and without daemonizing and spawning the necessary httpd children. httpd does not show up in the process list at all. there's a number of ways to figure out why, strace/truss, gdb, etc. I've tried to recompile httpd, but I keep getting segfaults when I try to use any mod_perl programs, and I was hoping that instead of troubleshooting a new compilation that perhaps it might be easier to resolve the once-working one. your version infos, etc. would help.
Re: Cookies and redirection
On Tue, 2 May 2000, Bill Desjardins wrote: Hi all, I checked the archives and the guide to no avail, so here goes. I am having trouble setting a cookie in the header and then doing a redirect. The cookies are working fine every where, but if I add a cookie to $r-headers_out-add(), set a location via $r-headers_out(Location = 'newrui') and return REDIRECT, I get no cookies being set. is this a bug, feature, or a feature of the wonderful world of incompatible browsers? try $r-err_headers_out-add instead.
RE: $r-get_handlers bug/oversight? (possible fix)
On Tue, 2 May 2000, Geoffrey Young wrote: ok, for anyone who is interested, I seem to have fixed the problem (maybe)... here's a patch for Apache.xs from yesterday's cvs (and I didn't see any commits since then...) --- Apache.xs.old Tue May 2 14:25:09 2000 +++ Apache.xs Tue May 2 14:26:19 2000 @@ -220,7 +220,7 @@ perl_handler_merge_avs(hook, avcopy); -return newRV_noinc((SV*)avcopy); +return newRV_inc((SV*)avcopy); } now, the implications of this are way over my head, but it seems to work with the test case below just fine (and my other code with which I initially caught the problem). anyway... hmm, that could result in a leak. i'll look into this soon, thanks for the details and patch!
Re: Why does $r-print() dereference its arguments?
On Wed, 3 May 2000, Jeffrey W. Baker wrote: Apache::print() dereferences its arguments. For example, this code: my $foo = "bar"; $r-print(\$foo); prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone explain the purpose of this behavior, or is it a misfeature? In my case, this is not the desired behavior. it only pulls that stunt for strings. assuming you're only printing the reference for debugging purposes, just stringify it first: my $foo = \"bar"; print "$foo"; or, geoff's trick: my $foo = "bar"; print \$foo . ""; do you need to avoid this feature for something other than debugging?
Re: Modperl/Apache deficiencies... Memory usage.
On Wed, 3 May 2000 [EMAIL PROTECTED] wrote: So what you want is something more general, climbs through the symbol table and can register callbacks for various things, right? One of right. which, the area I'm most interested in, is the PADLIST? Well, that's same here! certainly something that could be put together. What I had worked on and have right now is something that is adapted out of Peek::Devel, (something like that..., I can't remember, by Ilya?) originally it was designed to trace through and report on the various variables in the PAD, but not too specific on data on that. So what we're talking yeah, Devel::Peek by ilya. about now is hooking up a module that you could register callbacks for PADs into secondary modules, reporters, cleaners, that sort of thing. Sounds cool to me :-). Now... how are we going to give this thing execution time?, is it something that is spun out as a thread everyonce in a while, or everpresent going through all the interpreters data? (Obviously this would only be possible in a fully threaded version of perl), or will it actually be part of the threads that are running perl scripts? (So that we won't have to deal with locking issues) the mod_perl-2.0 interpreter pool requires a -Dusethreads flavor of Perl, which is not 5.005 threads. it wraps the Perl runtime into the PerlInterpreter structure, which is thread-safe, assuming only one thread is calling back into it at any given time. so if mod_perl were to spawn a thread at startup, this thread could examine the mip-avail interpreters without any locking. Okay..., so in 2.x we're actually having threads that are dedicated to perl? I.e. seperate and apart from direct serving actions? Or did I misunderstand what you're saying here. So the cleaner would be an no, we have a pool of (thread-safe) PerlInterpreters created at startup (and at runtime as needed). at request time, inside an apache thread, we lock the interpreter pool, pop an interpreter from the avail list, push it into the busy list, unlock and and stash a pointer to the interpreter inside r-pool (or c-pool for connection handlers). that interpreter is used for any callbacks that happen in the request thread and is putback in the avail list at the end of the request (unless PerlInterpMaxRequests is reach or similar). internally triggered event, and run in the context of the running thread. It would say: "Hey I'm busy" and not get anymore requests, then it would start analyzing it's own data structures. Or are you speaking of a seperate thread running in the own variable space as the other threads which tells that thread to stop serving requests, and analyzes it's cloned version of the registry? just a seperate thread that plucks a mip-avail interpreter, puts it in the mip-busy list, analyzes, puts back, plucks the next mip-avail, over and over.
Re: Can't use Apache::exit() in command-line scripts
On Wed, 3 May 2000, Franco Finstad wrote:
I have a large modperl site with modperl (CGI) scripts and command-line perl
scripts.
My command line scripts load modules (.pm files) that use Apache::exit().
This is giving me the following errors:
**
Bareword "Apache::exit" not allowed while "strict subs" in use at
as/mod/Util.pm
line 546
**
you're calling exit in a module? shame on you. if you call exit() from a
script that is compiled by Apache::Registry (not include *.pm), exit()
will be overridden for you to call Apache::exit, no changes needed.
if you really want to call it in a module, which you really don't, do you?
try something like:
use subs qw(exit)
*exit = $ENV{MOD_PERL} ? \Apache::exit : sub { CORE::exit };
Re: Apache.pm failed to LOAD!
On Wed, 3 May 2000, Wang, Pin-Chieh wrote: Hi, I build the apache1.3.12 using mod_perl 1.23 on Solaris 2.6 machine, everything looks fine and installed successfully (at least the installation program told me so...) But when I start httpd using apachectl start, httpd did not start within error_log there is a message "Apache.pm failed to LOAD!" assuming you did 'make install' in the mod_perl directory, does adding 'PerlModule Apache' to your httpd.conf make any difference?
Re: Modperl/Apache deficiencies... Memory usage.
On Tue, 25 Apr 2000 [EMAIL PROTECTED] wrote: Let me know when you want the garbage collector. I'll re-write it in apache style, and add some debugging stuff. I figure there should be two pieces. One that analyzes the packages that are running, the other that actually kills off variables. This could be very usefull for admins that want to analyze what those huge processes really are. what i'd really like to see is a generic symbol table walker (written in c), where you can register callbacks foreach symbol type (SVt_*). then once you hit an SVt_PVCV, there can be any number of registered callbacks that fiddle with the padlist (cleaner, reporter, etc.) (Maybe like Apache::Memory::Cleaner, and Apache::Memory::Reporter?... how does that sound? We'd need some mutexes on the Registry so that the cleaner doesn't end up cleaning a running Registry Script well, duh!... should this extend to Handlers?) each interpreter clone has it's own copy of the symbol table and padlists (the syntax tree is shared). so, in a threaded apache, the cleaner could could pop a mip-avail interpreter and put it in the mip-busy list, in which case, nobody will try to use it, no locking needed (other than mip-mip_lock for the avail - busy shift and back again). mip == 'm'od_perl 'i'nterpreter 'p'ool, which is in the modperl-2.0 cvs tree, not quite nailed down, but getting close. in a 1.3-ish multi-process model, i suppose the cleaner could run as a cleanup. However, if it were possible to override the "read" and "write" functions that would sort of "freeze" execution, and put a lock on this Apache registry entry (and make a unlocked copy BTW), and transfer it to another thread whos only job was read/write through a sigqueue interface... that would be REALLY cool for performance/memory consumption. Much less context switching overhead, and drastically reduced memory overhead. The problem is that who in their right mind has time for this sort of thing? (:-) I was thinking of implementing the writing of mod_proxy like this..., after considering it fully though, I think it would be even better to write a generalized module that could stream bits to clients, and use it as a plug in for any module that doesn't want to waste time streaming out to a 28.8k connection. sounds like a piece of cake ;)
Re: 2.0 wishlist: consistent API and docs
On Wed, 26 Apr 2000, raptor wrote: What about a Apache2::XXX namespace for the new modules ...??! just asking. not quite, but there's a MP_INST_APACHE2=1 Makefile.PL attribute which will install everything relative to an Apache2/ subdirectory. this way 1.xx mod_perl and 2.xx can co-exist in the same site_perl tree then to enable 2.xx, just add 'PerlModule Apache2' in your httpd.conf, which adds the Apache2/ subdirs to your @INC path.
Re: Apache::VMonitor not loading..
On Wed, 26 Apr 2000, Alex Krohn wrote: Hi! I'm trying to get Apache::VMonitor to load on a new mod_perl 1.23/Apache 1.3.12/perl 5.005_03 installation. mod_perl is up and running fine, however I can't get Apache::VMonitor working. If I add [Wed Apr 26 16:13:45 2000] [error] Can't locate loadable object for module Apache::Util in @INC (@INC contains: you need to build mod_perl with PERL_UTIL_API=1 or EVERYTHING=1 or DYNAMIC=1 to enable Apache::Util
Re: mod_perl-1.99_01-dev
On Thu, 27 Apr 2000, Stas Bekman wrote:
On Tue, 25 Apr 2000, Doug MacEachern wrote:
On Fri, 21 Apr 2000, Greg Cope wrote:
Does this mean that we {will|may} be able to use the interpreter pool to
set up X Perl interpreters (say 20 to service dynamic handlers) with Z
apache (say 60 to handle static + dynamic content - assuming the dynamic
content is passed to the Perl interpreters) children, and hence have
significant memory savings as we can avoid (in some cases) the light / heavy
httpd model ?
yes, exactly.
But you will be not able to tune the two types of the threads to have
different Apache parameters (MaxRequests and others) so I'm not sure you
will get rid of the dual setup, unless these will be taken care of by
mod_perl.
well, there is a PerlInterpMaxRequests parameter in 1.99_01-dev, which
knocks off the Perl clone after x number of requests. in addition, the
pool of interpreters are pulled and putback from the head of the list, so
you are getting re-used allocations (e.g. padlists aka lexicals). that
is, say you configured PerlInterpStart to 10, but average no more than 5
concurrent requests. you have 5 clones with allocated padlists, and 5
which are much smaller (but ready for conncurrent requests 5). this is
unlike 1.3 where you have 10 children, chances are high each of them will
endup will allocated padlists, as there's no control over which child
handles a request.
i'm not saying 2.0 will rid the need for a dual setup, but the Perl side
is looking a whole lot smaller (er, less fat) at this point.
