Re: Segmentation Fault: RedHat 6.[01] / Apache 1.3.12 / mod_perl1.22 / perl 5.005_03 / IE 5
On Thu, 30 Mar 2000, Robert Jenks wrote: I'm having a very strange problem. I'm running a very large application under apache/mod_perl (100+ modules; httpd children grow to 40+MB). The application uses Apache::DBI (DBD::Oracle) CGI.pm, so I have it running as a handler and everything works fine except... :) If the first request to httpd comes from IE5 to the web root, the child httpd process will segfault. However from any other client I've tried ( Netscape Comm. and "telnet 0 80 GET /" it works fine and doesn't segfault. Even stranger, if I point IE5 at "/perl-status?inc", and then at "/" it doesn't segfault (from that point forward it doesn't segfault; even if it hits a new child httpd). see the SUPPORT doc for hints on getting a stacktrace, that should help find the culprit.
Re: httpd coredumps
On Mon, 3 Apr 2000, Tobias Brox wrote: if you could follow the hints in the SUPPORT doc for getting a stacktrace, that would help a great deal. Here we are ... hm ... it doesn't seem to tell much. The request is after the server root, and I haven't set up any perl handlers ... so then it shouldn't call perl_handler() ... or what? the stacktrace looks right. it would be more useful to see the line number, which you can see if you follow this tip for building mod_perl from the SUPPORT doc: =item CORE DUMPS If you get a core dump, please send a backtrace if possible. Before you try, build mod_perl with perl Makefile.PL PERL_DEBUG=1 which will: -add `-g' to EXTRA_CFLAGS -turn on PERL_TRACE -set PERL_DESTRUCT_LEVEL=2 (additional checks during Perl cleanup) -link against libperld if it exists
Re: Set DocumentRoot from modperl
there have been several requests for the ability to modify the
DocumentRoot, i reckon it's about time we allow that.
caveats:
if you want the DocumentRoot to be reset to the original value after the
request is over, you'll have to do that yourself, something like:
my $old_docroot = $r-document_root;
$r-register_cleanup(sub { shift-document_root($old_docroot) });
the lifetime of conf-ap_document_root is longer than that of r-pool, so
it can't be used to allocate the string copy.
we could use the server pool, which isn't destroyed until the server is
restarted, but then each time you set document_root, the server would
"leak" memory.
to workaround, the new document_root is saved in a Perl variable
$Apache::Server::DocumentRoot
--- src/modules/perl/Apache.xs 2000/04/03 04:48:52 1.92
+++ src/modules/perl/Apache.xs 2000/04/03 05:36:56
@@ -783,8 +783,26 @@
Apacher
const char *
-document_root(r)
+document_root(r, ...)
Apacher
+
+PREINIT:
+core_server_config *conf;
+
+CODE:
+conf = (core_server_config *)
+ get_module_config(r-server-module_config, core_module);
+
+RETVAL = conf-ap_document_root;
+
+if (items 1) {
+SV *doc_root = perl_get_sv("Apache::Server::DocumentRoot", TRUE);
+sv_setsv(doc_root, ST(1));
+conf-ap_document_root = SvPVX(doc_root);
+}
+
+OUTPUT:
+RETVAL
Re: Perl 5.6 and mod_perl
On Thu, 30 Mar 2000, Rodney Broom (OE) wrote: U guess. Lots of weird little errors that I can't quite resolve. I can get Apache installed, but if I build with mod_perl, I can't get cgi or indexing to work. They just spit out segment fault errors. if you could follow the hints in the SUPPORT doc for getting a stacktrace, that would help a great deal.
Re: Error on CGI execution
On Fri, 31 Mar 2000, Paolo Tealdi wrote: Hello all. What exactly means this error (from my error_log ) "Attempt to free non-existent shared string during global destruction. " It is from a big CGI ported in mod_perl. Unfortunately i haven't written it (the CGI, not mod_perl :-) ) and i'd like to have some more explication on this error to search it in the source. that error can only be triggered during child_exit(), which calls perl_destruct(). what version of Perl are you running? any xs modules in the mix?
RE: Segmentation Fault: RedHat 6.[01] / Apache 1.3.12 / mod_perl 1.22 / perl 5.005_03 / IE 5
On Fri, 31 Mar 2000, Vivek Khera wrote: "GY" == Geoffrey Young [EMAIL PROTECTED] writes: GY PerlFreshRestart causes a great many problems, most for indeterminate GY reasons, but its behavior is at least documented I'm curious, now with the new code in 1.22 that dl_unloads all of the perl XS modules and with the perl shared object also being unloaded, doesn't PerlFreshStart cause a whole new perl interpreter to be instantiated? I haven't investigated this but it seems to make sense. Has anyone looked into this? mod_perl dso will do a full tear-down (perl_destruct()), regardless of PerlFreshRestart (which still behaves the same old way)
Re: installing with apache
After having compiled mod_perl and apache together, shouldn't mod_perl be enabled in httpd.conf? It isn't. Have I done things correctly? no, you need to add the mod_perl configuration to httpd.conf yourself.
Re: what's the apache mod_perl speedup factor?
tom, my direct reply to you bounced, but this should probably be on the list anyhow... - Transcript of session follows - ... while talking to mail.perl.com.: MAIL From:[EMAIL PROTECTED] 550 Your site is blacklisted as a spam haven. 554 [EMAIL PROTECTED]... Service unavailable On Fri, 31 Mar 2000, Tom Christiansen wrote: Any rough rule-of-thumb scaling factor for how much faster running an averaged sized CGI script under mod_perl is compared with firing it up each time? For example, 2x? 5x? 10x? 20x? 40x? Obviously this depends on a lot of factors, but perhaps there's something on can say that's more generally true than it is false? --tom there's an attempt at benchmarking mod_perl vs. foo here: http://www.chamas.com/bench/index.html and a simple test you can run in the mod_perl-x.xx directory: % ../apache-1.3/src/httpd -d `pwd`/t -f `pwd`/t/conf/httpd.conf % perl benchmark/lwp-simple.pod Benchmark: timing 50 iterations of cgi, perl... cgi: 16 wallclock secs ( 0.63 usr + 0.10 sys = 0.73 CPU) @ 68.49/s (n=50) perl: 1 wallclock secs ( 0.31 usr + 0.05 sys = 0.36 CPU) @ 138.89/s (n=50) (warning: too few iterations for a reliable count) % kill `cat t/logs/httpd.pid` that runs 50 requests each to /cgi-bin (mod_cgi) and /perl (mod_perl) for the same script, t/net/perl/cgi.pl i don't have enough data to support a statement that mod_perl is x times faster that mod_cgi, like you say, it depends on a lot of factors.
Re: mod_perl (DSO) dumping core with perl 5.6.0
On Fri, 31 Mar 2000, Paul G. Weiss wrote:
Please help. I've tried many things. I'm building this on
Solaris 2.6.
I'm tring to get mod_perl (1.22) to load as a DSO. It is dieing as
follows:
that's a shame, Perl 5.005_56-ish worked fine as a dso under solaris.
mod_perl's Makefile.PL tries to suggest alternatives, you'll have to
choose one of these (ignoring #2) for the moment:
if (($USE_DSO or $USE_APXS) and $] 5.005_56 and
$^O eq 'solaris' and $Config{'usemymalloc'} eq 'y')
{
phat_warn(EOF);
Your current configuration will most likely trigger core dumps,
suggestions:
*) Do not configure mod_perl as a DSO
*) Upgrade your Perl version to 5.005_56 or higher
*) Configure Perl with -Uusemymalloc
*) Switch to an os other than $^O
EOF
}
Re: Problem Compiling with Perl 5.6.0
On Thu, 30 Mar 2000, Steve Hay wrote:
Thanks for this!
I tried it with the latest mod_perl cvs: mine now compiles perfectly too
(_never_ seen that before!!!), and there's now only 1 unresolved external
symbol instead of 7. Looks like it could be nearly there - I'll try another
one some time.
lemme guess, Perl_rsignal? somehow i managed not to commit this
yesterday, it's in cvs now. i don't have a win32 system to test on at the
moment, so any feeback from you, Randy K and others helps a great deal,
thanks.
--- src/modules/perl/mod_perl.c 2000/03/30 00:20:34 1.109
+++ src/modules/perl/mod_perl.c 2000/03/30 19:32:22
@@ -1099,6 +1099,7 @@
cfg-pnotes = Nullhv;
}
+#ifndef WIN32
sigs = (perl_request_sigsave **)cfg-sigsave-elts;
for (i=0; i cfg-sigsave-nelts; i++) {
MP_TRACE_g(fprintf(stderr,
@@ -1108,6 +1109,7 @@
(unsigned long)sigs[i]-h));
rsignal(sigs[i]-signo, sigs[i]-h);
}
+#endif
}
void mod_perl_end_cleanup(void *data)
Re: Modperl 1.22 and Perl 5.6.0
On Wed, 29 Mar 2000, Jeffrey W. Baker wrote: configure Perl with -Dusemymalloc Wait, doesn't usemymalloc mean to use the system's native malloc? This from INSTALL: "To build without perl's malloc, you can use the Configure command sh Configure -Uusemymalloc" yeah, -Uusemymalloc means to use native malloc, notice i suggested -Dusemymalloc, which means to use Perl's malloc. On Linux 2.2, Perl uses its own malloc by default. To use the native malloc, specify -Dusemymalloc. It might be amusing to compare the two, as Linux has a very fast malloc implementation. -U == undefine usemymalloc (use system malloc) -D == define usemymalloc (use Perl's malloc) i've benchmarked the two, it makes a HUGE difference under solaris, Perl's malloc kicks the sh*t out of solaris system malloc. Perl's malloc is not as much of a win under linux, i don't have the numbers handy though.
Re: [Patch] Apache::DB on Win32
thanks Gerald, applied for 0.07. On Wed, 29 Mar 2000, Gerald Richter wrote: Hi Doug, the following patch allows Apache::DB to be used on Win32 Systems: In DB.xs wrap the SIGINT call at the last line inside a conditional, like: #ifndef WIN32 if (ApacheSIGINT) (*ApacheSIGINT)(SIGINT); #endif Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: getting mod_perl working
try 1.22 instead of 1.21 On Wed, 29 Mar 2000, Quadrilateral I was wrote: I've been trying to get ePerl installed on a redhat system, and I seem to have narrowed it down to a problem with mod_perl and/or apache. Whenever I add a PerlModule statement to httpd.conf and try to restart httpd, it won't run. Doesn't give me any error messages--it just refuses to work. I've tried it with both 'PerlModule Apache::Status' and 'PerlModule Apache::ePerl', and I've also tried it on two different systems--both running apache 1.3.9 and mod_perl 1.21, freshly installed. Any idea what I could be doing wrong? Joel Young . . . .::.: * . . .We're all mad here. [EMAIL PROTECTED] * ** ' 'I'm mad. http://lo.res.cmu.edu/reverie/ ' You're mad.
Re: [make test warns] mod_perl/mod_ssl
httpd.conf should have: IfModule mod_ssl.c SSLDisable SSLSessionCache none /IfModule ok, applied, thanks!
Re: Can't locate object method OPEN via package Apache
On Thu, 30 Mar 2000, Sam Carleton wrote: I am trying to get the Apache::Magick module from the O'Reilly book "Writing Apache Modules with Perl and C" to work. The error I am running into is: Can't locate object method "OPEN" via package "Apache" (line 80) The looks real simply: open(STDOUT, "=" . fileno($fh)); try adding: untie *STDOUT; before the open(...)
Re: More segfault problems
On Wed, 29 Mar 2000, Shevek wrote: I can't find any documentation for what RULE_EXPAT does, the only occurrence at all is in Apache src/Configure, where it seels to compile in the expat lite library. RULE_EXPAT=no disables the expat lite library. there have been reports of it clashing with symbols in XML::Parser
Re: performance mongers: since when is using CGI.pm or Apache::Registrydishonorable?
geez. i don't recall "Apache::Registry vs. pure PerlHandler" or "Apache::Request vs. CGI.pm" ever being so harsh. but they have been compared, for good reason. Apache::Registry maps a request to a file and generates a subroutine to run the code contained in that file. if you use a 'PerlHandler My::handler' instead of Apache::Registry, you have a direct mapping from request to subroutine, without the steps inbetween. these steps include: stat the $r-filename check that it exists and is executable generate a Perl package name based on $r-uri chdir basename $r-filename compare last modified time if modified or not compiled, compile the subroutine chdir $old_cwd if you cut out those steps, you cut out some overhead, plain and simple. do you NEED to cut out that overhead? i don't know, your requirements determine that. as for CGI.pm vs. Apache::Request. last i checked 'use CGI qw(-compile = ':all') adds 1Mb size to the server. CGI.pm pulls lots of stunts under the covers to provide both a method and function interface, etc. Apache::Request is a very thin xs layer on top of a C library and only adds a few k size to the server. this C code is much faster and lighter than the Perl equivalent used in CGI.pm or similar (e.g. CGI_Lite). again, this difference might not matter much to you, depending on your requirements.
Re: [admin] NO HTML posts please!
esrever ni snoitseuq gnirewsna diova esaelp dna On 30 Mar 2000, Randal L. Schwartz wrote: "Angel" == Angel R Rivera [EMAIL PROTECTED] writes: Angel how about avoiding the me toos... Yeah, and the people that post "upside down", with the answer *before* the question! Definitely. Let's avoid those.
Re: [PATCH 5.6.0] local $SIG{FOO} restoration
On Wed, 29 Mar 2000, Hugo wrote:
I believe that this (or take2) might cause a problem for code like:
sub handler { print "sig handled" }
my $handlesub = "handler";
[... something reads $handlesub in numeric context ...]
$SIG{ALRM} = $handlesub;
i suppose the handler should not be restored if it was Perl's, something
along the lines of (on top of take2 patch):
--- mg.c~ Tue Mar 28 23:44:09 2000
+++ mg.cThu Mar 30 11:50:05 2000
@@ -966,7 +966,7 @@
/* cache state so we don't fetch it again */
if(sigstate == SIG_IGN)
sv_setpv(sv,"IGNORE");
- else if (sigstate)
+ else if (sigstate sigstate != PL_sighandlerp)
sv_setiv(sv,(IV)sigstate);
else
sv_setsv(sv,PL_sv_undef);
Re: [ANNOUNCE] mod_perl-1.22
On Thu, 23 Mar 2000, Ruben I Safir wrote: Is there any security issues forcing an upgrade? no.
Re: [patch] mod_perl-1.22 and SGI_BOOST
On Fri, 24 Mar 2000, Ville Skyttä wrote: The -DSGI_BOOST option is broken in mod_perl 1.22 (minor typo), a patch is attached. thanks, applied. Further, the "perl Makefile.PL" section of the installation has changed somewhat from 1.21_03, resulting in some strange warnings / errors. these should all be fixed now in the cvs tree, thanks for the report!
Re: Re-coding some noddy routines in C
On Fri, 24 Mar 2000, Dave Hodgkinson wrote: General question: We have two little bits of mod_perl code we run, one that pops our accellerating proxy IP address off the X-Forwarded-For list and the other that stuffs one of a variety of possible cookies into the basic auth field of the logger. I need these functions in a couple of servers, ones that don't need to hae mod_perl if I can re-code these modules. How easy is it to do this in C? This is all covered in the Eagle book? should be simple. the api is covered in the eagle book, also have a look at the C examples at modperl.com (which are not in the book), and libapreq (cpan.org/modules/by-module/Apache), includes C examples for using the cookie api.
Re: Modperl 1.22 and Perl 5.6.0
On Fri, 24 Mar 2000, Ken Kosierowski wrote: What is the best way to compile the new Perl 5.6.0 with Modperl 1.22? same way you compile 5.005 with mod_perl Should I use the 5.005 compatible flags or start from scratch and recompile the modules I use? you don't need the 5.005 compat flags to build mod_perl-1.22 Are there performance issues using the 5.005 compat mode? not sure, doubt it though. What about malloc and malloc flags -- same as what the Guide recommends? i the guide recommendations (TWO_POT_OPTIMIZE, etc) are the default since 5.005. i think linux still defaults to system malloc, you might want to configure Perl with -Dusemymalloc What about issues with the upcoming Apache 2.0 and modperl 2.0? mod_perl-2.0 will be underway soon.
Re: More segfault problems
On Fri, 24 Mar 2000, Shevek wrote: Now we get rid of the DOM tree. 44 $document-dispose; And the child segfaults. But if I don't have the dumper, that does not happen. What is the best way to get around this? Is undefining $d an appropriate technique? did you configure apache with RULE_EXPAT=no ?
Re: Why 'require' required?
On Sun, 26 Mar 2000, Jie Gao wrote: Another thing is, it seems there is no way to get at "allow/deny from" from within mod_perl. "deny from all" will work, but "deny from ip.addres." does not. no, because the allowdeny typedef is private in mod_access.c however, you can implement directive handlers for allow and deny that capture the data into a Perl object, then return DECLINE_CMD if you want mod_access to also pick up the allow/deny config.
Re: perl 5.6/mod_perl 1.22/apache 1.3.12
On Mon, 27 Mar 2000, Charles Day wrote: Just spent half the day trying marry these 3. mod_perl doesn't build. DSO/apxs errors as described by others. these errors were just warnings, try cvs if you want to get rid of them. did you have other problems too?
Re: why can not test, but can run
On Mon, 27 Mar 2000, David Yang wrote: I can not test my mod_perl, everytime I test my mod_perl, just as the document told me, it will letting apache warm up . failed what does t/logs/error_log say?
Re: Signal Abort
On Tue, 28 Mar 2000 [EMAIL PROTECTED] wrote: Hi, my environment is Server: Apache/1.3.3 (Unix) mod_perl/1.16 on Solaris, you might want to upgrade to recent versions of apache and mod_perl #26 0xee8e86b8 in IM_FreeMbox () #27 0xef4b8f14 in XS_Mailbox_DESTROY () if you can compile this Mailbox extension with debugging symbols (-g), the stacktrace might give more clues.
Re: possible bug: mod_perl 1.22 (Perl 5.6 / Apache 1.3.12)
On Tue, 28 Mar 2000, Dave Seidel wrote: and now everything is working correctly. What I don't undetrstand is that the original code was identical in mod_perl 1.21, but I didn't have this problem. Could this be due to some internal change in Perl 5.6? probably, thanks for the fix!
[PATCH 5.6.0] local $SIG{FOO} restoration
when 'local $SIG{ALRM} = sub {...}' goes out of scope, magic_setsig() sets
the SIGALRM handler to SIG_DFL, rather than the original handler. this
causes quite a bit of trouble running inside of apache, since 'local
$SIG{ALRM}' unhooks the apache SIGALRM handler for the life of that
proccess.
the original handler is already fetched by magic_getsig(), this patch
saves that pointer so it can be restored in magic_setsig().
--- mg.c~ Sat Mar 18 19:41:03 2000
+++ mg.cTue Mar 28 22:37:07 2000
@@ -967,7 +967,7 @@
if(sigstate == SIG_IGN)
sv_setpv(sv,"IGNORE");
else
- sv_setsv(sv,PL_sv_undef);
+ sv_setiv(sv,(IV)sigstate);
PL_psig_ptr[i] = SvREFCNT_inc(sv);
SvTEMP_off(sv);
}
@@ -1002,6 +1002,7 @@
I32 i;
SV** svp;
STRLEN len;
+Sighandler_t sigstate = 0;
s = MgPV(mg,len);
if (*s == '_') {
@@ -1038,16 +1039,21 @@
*svp = SvREFCNT_inc(sv);
return 0;
}
-s = SvPV_force(sv,len);
+if (SvIOK(sv)) {
+ sigstate = (Sighandler_t)SvIVX(sv);
+}
+else {
+ s = SvPV_force(sv,len);
+}
if (strEQ(s,"IGNORE")) {
if (i)
(void)rsignal(i, SIG_IGN);
else
*svp = 0;
}
-else if (strEQ(s,"DEFAULT") || !*s) {
+else if (strEQ(s,"DEFAULT") || !*s || sigstate) {
if (i)
- (void)rsignal(i, SIG_DFL);
+ (void)rsignal(i, sigstate ? sigstate : SIG_DFL);
else
*svp = 0;
}
[ANNOUNCE] mod_perl-1.22
The URL http://perl.apache.org/dist/mod_perl-1.22.tar.gz has entered CPAN as file: $CPAN/authors/id/DOUGM/mod_perl-1.22.tar.gz size: 344615 bytes md5: 5ec093c3b11c5b411d28aa1447b4a0bc Changes since 1.21_03: proxy support fixed wrt RFC2068, thanks to Benjamin Elijah Griffin for the spot set Apache::Resource::DEFAULT_RLIMIT_AS (address space) to 64Mb [Kevin Murphy [EMAIL PROTECTED]] Bundle::Apache will now install Bundle::LWP before mod_perl [Aaron Johnson [EMAIL PROTECTED]] support Apache::FakeRequest::args in a list context [Michael Finke [EMAIL PROTECTED]] compile fixes for 5.6 + -Duse5005threads [Lincoln Stein [EMAIL PROTECTED]] log to parms-server instead of stderr if PerlRequire fails make sure lib/Apache/MyConfig.pm is written before used thanks to Albert Chin for the spot fixup the output of apxs -q CFLAGS to preserve quoting (again) --- Enjoy, -Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] mod_perl-1.21_03
The URL
http://perl.apache.org/dist/mod_perl-1.21_03.tar.gz
has entered CPAN as
file: $CPAN/authors/id/DOUGM/mod_perl-1.21_03.tar.gz
size: 343622 bytes
md5: c76342b8b576e0c59d4f5bf4d347ca0a
this is very close to 1.22, hopefully no longer than another day or two
away.
Changes since 1.21_02:
removed the generated apaci/mod_perl.config from MANIFEST
new variable $Apache::Server::StrictPerlSections, if true, will croak
Perl section generates invalid Apache configuration syntax
new Apache::src-ccflags method to combine $Config{ccflags} and
apxs -q CFLAGS
[Matthias Urlichs [EMAIL PROTECTED]]
added Apache::src-apxs method
make use of $Config{shrpenv} to find CORE/libperl.so
[Ignasi Roca Carri [EMAIL PROTECTED]]
fix Apache::Registry bug when filename starts with a 0
[Peter Deister [EMAIL PROTECTED], Ken Williams
[EMAIL PROTECTED]]
Apache::Registry will restore $r-status to the original value
[Charles Levert [EMAIL PROTECTED]]
warn aix-apxs-5.005_03 users of the patch needed for DynaLoader
[Jens-Uwe Mager [EMAIL PROTECTED]]
fixup the output of apxs -q CFLAGS to preserve quoting
[Sheldon Hearn [EMAIL PROTECTED]]
dso fix fix: modules with END blocks calling xs code (e.g. DBI) would
core dump because the xs .dso had been unloaded, now dso's are not
unloaded until after END blocks are called.
Thanks to Daniel Jacobowitz and others for spotting
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: setting perl handler based on MIME type?
On Thu, 27 Jan 2000, Jim Winstead wrote:
Is there a way to set a PerlHandler for a specific MIME type?
Something like "PerlTypeHandler text/html HTML::Template"?
(Yes, I know I can use a Files section. Not quite as slick,
and that mucks up $r-location.)
there's no builtin config like that, though you could to magic with
directive handlers. otherwise, something like this should work:
package My::MimeTypeDispatch;
my %mime_types = (
'text/html' = \HTML::Template::handler,
);
sub handler {
my $r = shift;
if (my $h = $mime_types{$r-content_type}) {
$r-push_handlers(PerlHandler = $h);
$r-handler('perl-script');
}
}
__END__
PerlFixupHandler My::MimeTypeDispatch
Re: Static linking of Sybase::DBlib to mod_perl?
On Thu, 27 Jan 2000, Thomas Corte wrote: Hi, I'd like to use sybperl from a (statically linked) mod_perl httpd. I only have older non-PIC sybase client libraries here (the OS is hp/ux), so I can't build sybase as a loadable object for perl. That is, it seems I have to compile mod_perl and sybase stuff statically into my httpd binary. From the docs, I got the info that adding Sybase::DBlib to PERL_STATIC_EXTS should do the trick. Indeed, I got a httpd binary which is about 200k bigger than without this addition. However, "use Sybase::DBlib" in a mod_perl script still yields Can't locate loadable object for module Sybase::DBlib in @INC I wonder why perl still looks for a loadable object here. Is it possible at all to link the sybase stuff into httpd? Or will I have to buy more recent PIC-compiled client libraries? does apache-x.x.x/src/modules/perl/perlxsi.c have a DBlib reference? you should see something like: boot_Sybase__DBlib
Re: mod_perl and Content-Negotiation
On Thu, 27 Jan 2000, Bruce W. Hoylman wrote: I see Apache::RegistryNG @ISA Apache::PerlRun. Furthermore, perldoc Apache::PerlRun states the following: The Apache::Registry handler is much faster than Apache::PerlRun. However, Apache::PerlRun is much faster than CGI ... This would seem to imply Apache::Registry is also much faster than Apache::RegistryNG. Apart from the filename vs. uri namespace difference and the OO nature of Apache::RegistryNG, are there any compelling reasons to consider RegistryNG over Registry? the docs are refering to Apache::Registry::handler vs. Apache::PerlRun::handler. aside from the handler(), the rest of Apache::PerlRun contains all the functionality of Apache::Registry broken down into several subclass-able methods. this methods are used by Apache::RegistryNG to implement the exact same functionality of Apache::Registry, using the Apache::PerlRun methods. Apache::PerlRun::handler should probably be in another namespace to avoid this confusion. there is no compelling reason to use RegistryNG over Registry, unless you want to do add/change functionality of the existing Registry.pm. for example, Apache::RegistryBB (bare-bones) is another subclass that skips all the stat()s.
Re: Problems building GTop...
On Thu, 27 Jan 2000, Stas Bekman wrote: Hmm, let's see Doug wrote GTop... so is this ontopic? :) Check the libgtop homepage for more info and help. (hint: README file includes the URL) hmm, well I didn't put any email address in the GTop package :) Apparantly, you either don't have it installed or installed in some different place that the compiler doesn't know about. I suggest rebuilding the libgtop from scratch and it'll all work (remove the SuSe package first so there won't be any collisions). I don't have SuSe so I cannot share my experience with you. I run suse. Ken you just need to install libgtop and glib before building GTop.
Re: mod_perl and Content-Negotiation
On Thu, 27 Jan 2000, Stas Bekman wrote: * Apache::RegistryNG doesn't stat() the script on each request, like Registry does. not true, RegistryNG is the same as Registry, aside from using filename instead of uri for the namespace. you're thinking of RegistryBB Doug will have to confirm my guesses. He endorses the use of NG for a long time, but the habits are hard to change :) So you will be the pioneer, isn't it exciting? I'm not convinced NG is the final solution, but something like it where the functionality is broken apart and re-usable, unlike the existing Registry.pm where everything is all lumped in together.
Re: Results of calling perl_shutdown in mp_dso_unload
On Fri, 21 Jan 2000, Daniel Jacobowitz wrote: (with appropriate changes to unload DSOs after shutting down perl, of course). I still get memory leakage - that's not terribly surprising - but it is much less. It's on the order of about 24K/restart and is probably the fault of some module - my guts would be DBD::Pg. I'll play around with that later. It's small enough to show that the idea is workable. Restarts are also a bit slower, unsurprisingly - there's a lot more to do. right, that's one of the reasons restarts are a noop for mod_perl by default (not including dso-magic) Then we have the fact that this currently removes PerlRestartHandler functionality and goes far beyond PerlFreshRestart. Those are a big issue - those will HAVE to work differently depending on whether or not mod_perl is a DSO. If not, they can continue to work as before, but if it is they will never be invoked. I'll clean up the patch and fire it off later this weekend, if Doug doesn't get a chance to look at it before then. Doug is slowly crawling back from the death flu :-/ I'm think about releasing 1.22 as it stands in the cvs tree, since it's so long overdue, and bang out the dso issues from there. as much as I want to cure the dso problems, I don't want to introduce new problems the currently stable static configuration.
RE: mod_perl 1.21 - CGI.pm 2.56 error in phase other than conten t
from chapter 9 of wrapmod:
There are a number of standard variables that Apache adds to the
environment prior to invoking the content handler. These include
DOCUMENT_ROOT and SERVER_SOFTWARE. By default, the complete C%ENV
hash is not set up until the content response phase. Only variables
set by BPerlPassEnv, BPerlSetEnv and by Imod_perl itself will be
visible. Should you need the complete set of variables to be
available sooner, your handler code can do so with the
Isubprocess_env method. Example:
my $r = shift;
my $env = $r-subprocess_env;
%ENV = %$env;
On Wed, 22 Dec 1999 [EMAIL PROTECTED] wrote:
PerlPostReadRequestHandler 'sub { Apache-request(shift) }'
doug,
thanks for the response. I had tried the bandaid with no luck.
Probably should have said that in the post :-)
Ok having realised that the Handler wasn't getting called as I already had
another PerlPostReadRequestHandler being called the issue is getting
clearer
I am trying to call CGI within a PerlAuthenHandler
I can new correctly create the CGI object, i.e. it no longer falls over on
registering it's callbacks. However it does not get any of the data. Now I
presume this is because the CGI environment is not yet set up. In the
server log it appears to be working offline.. So I tried adding to the
environment before calling CGI-new setting REQUEST_METHOD CONTENT_LENGTH
and CONTENT_TYPE. This creates the object correctly (but without any
parameters) on a POST request. It would appear that CGI is not getting
anything from STDIN. At the moment I can work around this by calling
cgi-param for each bit of $r-content, I was just wondering if there is a
better way fro all of this ?
SAM
Re: PerlRun and Exporter() vars
On Mon, 27 Dec 1999, John M Vinopal wrote:
More about the undef of package variables. Sure enough, the variables are
nuked in PerlRun::flush_namespace(). This can be inhibited by removing
them from the script's namespace before termination:
my $name = __PACKAGE__ . '::';
delete($name-{'VARIABLE NAME HERE'});
I notice that the 1.17 bug about undefing subroutines was fixed by adding
some checking code PerlRun::undef_cv_if_owner(), should this same sort of
thing be done for variables as well?
yes, sounds like that's the case. thanks for the insights. ToDo
Re: Status in httpd access log
have a look at Apache::RedirectLogFix
On Thu, 6 Jan 2000, Mark Nudelman wrote:
I'm writing my first module using modperl, so I'm probably doing
something really wrong, but I haven't been able to figure this out. I
want my script to return an HTTP error code to the client, and I want
that error code to be logged to the httpd access log. If I use this
script:
my $r = Apache-request;
$r-status(304);
everything works as expected: the client receives a "304 Not Modified"
status line, and the log shows a "304" status.
But if I do this:
$r-status(304);
$r-err_header_out("X-Test-Header" = "abc");
$r-send_http_header();
then the client still receives the 304 status as expected, as well as
the extra header, but the log shows a status of 200, not 304. In fact,
the err_header_out doesn't matter; if I just call send_http_header, the
log shows 200. How can I make the log show the correct status?
Another problem is that in some cases, such as if I return a "400 Bad
Request" status, I'm getting a "Connection: close" header as well. Is
there any way I can control this? I don't want to send a Connection:
close header, even if I return an error status.
Thanks for any help,
--Mark
Re: Perl modules in apache configuration
if you compile modperl with PERL_TRACE=1 and setenv MOD_PERL_TRACE s then you should see some useful diagnostics when mod_perl is processing Perl sections. On Sun, 9 Jan 2000 [EMAIL PROTECTED] wrote: Hello! I'm trying to configure httpd.conf using Perl sections (mod_macro is not enough for me), but the result is weird. The most weird thing is that Perl sections randomly doesn't execute! I have no experience (yet) with Perl configuration modules, so I don't understand where to start tracking. mod_perl developers' guide didn't help, as perldoc mod_perl :-( -- Alexander B. Povolotsky[ICQ 18277558] [2:5020/145][[EMAIL PROTECTED]]
Re: Memory leak/server crashes
there are hints in the SUPPORT doc on how to debug such problems. there
was also several "Hanging process" threads in the past weeks with more
tips, search in the archives for keywords gdb, .gdbinit, curinfo
if you can get more insight from those tips, we can help more.
On Sun, 9 Jan 2000, James Furness wrote:
I'm looking for some help getting apache to run reliably. Apache 1.3.9 with
mod_perl 1.21 and Perl 5.005_03 is running on a dual P500 with 1 Gb of RAM
running Redhat 6.1. We run about 5 sites off the box, most of which are
fairly high traffic, and use a lot of CGI and
MySQL 3.22.25 is used with Apache::DBI.
The major problem seems to be a memory leak of some sort, identical to that
described in the "memory leak in mod_perl" thread on this list from October
1997 and the "httpd, mod_perl and memory consumption (long)" thread from
July 1997.
The server runs normally for several hours, then suddenly a httpd process
starts growing exponentially, the swapfile usage grows massively and the
server starts to become sluggish (I assume due to disk thrashing caused by
the heavy swap usage). Usually when this started to happen I would log in
and use apachectl stop to shutdown the server, then type 'killall httpd'
several times till the processes finally died off, and then use apachectl
start to restart apache. If I was not around or did not catch this, the
server would eventually become unresponsive and lock up, requiring a manual
reboot by the datacentre staff. Messages such as "Out of memory" and
"Callback called exit" would appear in the error log as the server spiralled
down and MySQL would start to have trouble running.
To combat this, I created a script to monitor load and swapfile usage, and
restart apache as described above if load was above 7 and swapfile usage
above 150Mb. This script has kept the server online and we now have an
uptime of something like 22 days (previously no more than 1 day), but the
script is getting triggered several times a day and no more "Out of memory"
messages are appearing, but the situation is not ideal.
I have tried adding:
sub UNIVERSAL::AUTOLOAD {
my $class = shift;
Carp::cluck "$class can't \$UNIVERSAL::AUTOLOAD!\n";
}
As recommended by the developers guide, which flooded the error log with the
text below being printed roughly once a second in the error log:
-
Apache=SCALAR(0x830937c) can't $UNIVERSAL::AUTOLOAD!
Apache=SCALAR(0x8309364) can't $UNIVERSAL::AUTOLOAD!
DBI::DBI_tie=HASH(0x82dd16c) can't $UNIVERSAL::AUTOLOAD!
IO::Handle=IO(0x820aabc) can't $UNIVERSAL::AUTOLOAD!
DBI::DBI_tie=HASH(0x82dd16c) can't $UNIVERSAL::AUTOLOAD!
IO::Handle=IO(0x820aabc) can't $UNIVERSAL::AUTOLOAD!
DBI::DBI_tie=HASH(0x82dd16c) can't $UNIVERSAL::AUTOLOAD!
IO::Handle=IO(0x820aabc) can't $UNIVERSAL::AUTOLOAD!
DBI::DBI_tie=HASH(0x82dd16c) can't $UNIVERSAL::AUTOLOAD!
IO::Handle=IO(0x820aabc) can't $UNIVERSAL::AUTOLOAD!
--
I've pretty much exhausted any ways I can think of to trace this problem,
such as i've tried to eliminate memory leaks in code by removing some
scripts from mod_perl and running them under mod_cgi and i've tried tweaking
MaxRequestsPerChild both without any success.
One thing that was mentioned in a previous thread was that using 'exit'
could confuse perl, and exit() is used fairly heavily in the scripts since
most are converted to mod_perl from standard CGIs, but i'd prefer not to
have to remove these since the structure of the scripts is reliant on some
form of exit statement. Is there some alternative to exit()?
I've also had a look at some of the patches to Apache.pm and Apache.xs
suggested in the previous threads, and these seem to have been incorporated
into mod_perl 1.21.
Are there any other solutions I could try to this problem? Does anyone know
what might be causing this?
The second problem I have is when loading pages, usually CGI, but I think
this has happened on some static pages, what IE5 describes as "Server not
found or DNS error" is experienced. Originally I thought this was the server
hitting MaxClients (150) since it usually occurs at the same time as massive
surges of hits, and /server-status usually shows 150 httpd processes have
been spawned, however I increased MaxClients to 200 recently and the error
has continued to happen, even though /server-status doesn't show any more
than about 170 processes spawned. I have not ruled out DNS server troubles
or backbone problems (We've had a few routing troubles recently that slowed
things down, but not actually cut off traffic or anything like that), but I
am at a loss as to what else could be causing this so I thought i'd ask
whilst i'm on the subject of server problems :)
Thanks in advance,
--
James Furness [EMAIL PROTECTED]
ICQ #: 4663650
Re: Help
sounds like your script is running under mod_cgi, not mod_perl On Tue, 11 Jan 2000, Akio wrote: I´m programming in mod_perl and I'm trying to use libapreq-0.31 but when I call method new, I get the msg "Can't locate object method "new" via package "Apache::Request"". The package (module) that use it has a statement "use Apache::Request ( )" and the next statement is : my $r= Apache::Request-new(shift); I have it installed in a Sun Solaris server (not i86) and I´m using Perl 5.005. I have downloaded it from CPAN site. Anyone can help me?
Re: problems with module at root of web site
On Wed, 12 Jan 2000, Sean Chittenden wrote: Mind if I ask a nit-pick of a performance question? Currently speed and performance are of upmost importance (I'm currently involved in a mod_perl vs JServ development race). That being said, isn't pushing a handler onto the request stack slower than predefining a handler that the request falls through to? I could be wrong and haven't tested things otherwise, but, it would seem like pushing a custom handler (granted it's already compiled into byte-code) onto the stack at the time of the request would take slightly longer. I suppose I'd be who of me to test this assertion, but if you have any idea as to wether or not this case ahead of time, I'd be greatly interested in hearing about your past experience. I don't think it would be a measurable difference. the only overhead using push_handlers vs. .conf is: -one Perl method call -growing the Perl*Handler array by 1, if it's not big enough already
RE: mod_perl bug (mod_perl 1.21; Apache 1.3.9).
On Wed, 19 Jan 2000, John Hughes wrote:
what happens if you preload Apache::Registry in httpd.conf:
PerlModule Apache::Registry
Didn't try that. But code examination seems to imply that it would have
no effect.
1. Apache::Registry gets run, so:
unless (defined $Apache::Registry::NameWithVirtualHost) {
$Apache::Registry::NameWithVirtualHost = 1;
}
Now NameWithVirtualHost is 1.
2. a non-virtualhost request is received so perl_handler in mod_perl.c does:
if((nwvh = ApachePerlRun_name_with_virtualhost())) {
if(!r-server-is_virtual) {
SAVESPTR(nwvh);
sv_setiv(nwvh, 0);
}
}
now NameWithVirtualHost is 0.
and it stays zero forever.
On reflection my fix is over the top - it has the effect of overriding
the value of NameWithVirtualHost set by the user.
I don't think perl_handler should be changing NameWithVirtualHost *AT ALL*,
that should be left up to the user, with a default in Registry.pm.
it used to be that way, but moved to perl_handler because it's a quicker
check in C, and multiple modules (besides Apache::Registry) need this
logic.
I attach patches to do that. They work for me.
thanks. I'll revisit this soon.
One last query, what about ApachePerlRun_namespace in PerlRunXS.xs, that
seems to think that the mere existence of the variable NameWithVirtualHost
implies that names should be modified with the virtualhost. It doesn't
check the *VALUE* of the variable:
that's okay, I don't think anybody is using PerlRunXS, I'd be surprised if
it still works at all. if there's to be a xs/c version ala PerlRunXS,
it's put off until modperl-2.0
Re: Suggested improvements to RegistryLoader.pm - stuff for virtualhosts
On Wed, 19 Jan 2000, John Hughes wrote: It would be nice if RegistryLoader.pm let me load a script for a virtual host in such a way that I didn't have to worry about how they were represented. Something like: my $r = Apache::RegistryLoader-new; $r-handler($uri, $filename, $virthost); looks good to me, thanks John!
Re: Problems w/ CGI under mod_perl
perhaps you should call
Apache-request-new($r)-register_cleanup(\CGI::_reset_globals);
there is no Apache::new method
the problem here (which has come up many times in the past), is that
CGI.pm uses the Apache-request method to get a reference to the global
$r. this normally isn't set until the response phase, unless you do it
yourself, which can be done with a line of config like so:
PerlPostReadRequestHandler 'sub { Apache-request(shift) }'
Re: horrible memory consumption
have a look at the Apache::Status in the cvs tree, there are hooks into B::TerseSize which is used to measure Perl memory usage. On Wed, 19 Jan 2000, Jason Terry wrote: Is there a way I can tell where my memory usage is going in an Apache child? I have a server that starts with acceptable numbers, but after a while it turns into this Server Version: Apache/1.3.9 (Unix) mod_perl/1.21 PHP/3.0.12 mod_ssl/2.4.4 OpenSSL/0.9.4 Redhat Linux: 2.2.13 PID USER PRI NI SIZE RSS SHARE LC STAT %CPU %MEM TIME COMMAND 9666 nobody-1-1 38900 37M 67681S0.07.5 6:57/usr/local/apache/bin/httpd 9665 nobody-1-1 35728 34M 62401S0.06.9 5:57/usr/local/apache/bin/httpd 9663 nobody-1-1 35312 34M 64121S0.06.8 6:11/usr/local/apache/bin/httpd Now I examined these children using /server-status and they had all recieved more than 7000 accesses for each child. Is there a way I can find out where all this RAM is being used. Or does anyone have any suggestions (besides limiting the MaxRequestsPerChild)
Re: send_fd and timeout problem
On Thu, 20 Jan 2000, Martin Lichtin wrote:
Doug MacEachern wrote:
mod_perl doesn't set it's own alarm when $r-send_fd is called. did you
call $r-print or print before hand?
Hmm, no, I do something like this:
$r-content_type('application/octet-stream');
my($size) = -s $fh;
$r-header_out('Content-Length', $size);
$r-send_http_header;
$r-send_fd($fh, $size);
close($fh);
you must be seeing logs from another process, none of those calls set an
'Apache-print' timeout.
Re: Performance ?'s regarding Apache::Request
On Thu, 20 Jan 2000, Clifford Lang wrote: mod_perl 1.21 Apache 1.3.9 Solaris 2.5.1, Linux 6.0 Is this a good or bad idea? I want to create an inheritable module based on Apache::Request mainly for uploading files, then create individual PerlHandler modules for individual page content. If I do this, will the uploaded files end up increase the memory consumption of the module, or is all memory freed after the fileupload process? Apache::Request reads the uploaded file in 4K chunks and saves it to a tmpfile, just as CGI.pm does. you shouldn't see the process grow to the size of the file unless you've hit a bug we don't know about.
Re: Can't exec programs ?
On Thu, 20 Jan 2000, Pierre-Yves BONNETAIN wrote: [EMAIL PROTECTED] said: you'll get a better idea of the problem running strace (or truss) against the server. in any case, you should avoid any code that's forking a process, since it's throwing performance out the window. Is there a 'nice way' (meaning, a patch or manual change I can do to those modules) to prevent forking or, rather, replace it by stg else that gets me the same thing ? I can spend (a lot of) time looking for system() and backticks in the modules I use, but if I need the functionnality how can I 'correct' the code of those modules ? I don't know of a tool to help with this, you just need to keep an eye on things with strace or truss and weed out the forking code.
Re: problem
On Thu, 20 Jan 2000, Etienne Pelaprat wrote: Hi All, I've hit a problem that I can't seem to rectify. I compile mod_perl with EVERYTHING=1, but in one of my modules, I get the error: [Wed Jan 19 20:30:05 2000] null: Rebuild with -DPERL_STACKED_HANDLERS to $r-push_handlers at /usr/local/apache/lib/perl/Apache/BOSCIndex.pm line 37. make sure the rebuilt httpd is the one you're using now. that's bitten plenty of us in the past. EVERYTHING=1 does enable stacked handlers. if you rebuild again, be sure to start with freshly unpacked source trees of both mod_perl and Apache.
Re: problem
On Thu, 20 Jan 2000, Cliff Rayman wrote: unfortunately PERL_STACKED_HANDLERS used to be experimental and therefore EVERYTHING includes just about EVERYTHING except PERL_STACKED_HANDLERS. i think you need to add PERL_STACKED_HANDLERS=1 to your long list of Makefile.PL parameters. this has been discussed in the mail archives so you can search there and you'll find the original message from Doug. no, PERL_STACKED_HANDLERS is including with EVERYTHING=1
Re: CGI.pm and QUERY_STRING fixup
On Mon, 24 Jan 2000, Bill Moseley wrote:
...
Under mod_cgi I can clean up $ENV{QUERY_STRING} at the start of a program
by removing leading '' and double '', but that doesn't work, obviously,
under mod_perl.
Could someone suggest a way to clean up the query string from within an
Apache::Registry script? Is it possible to just write a cleaned up query
string to args() at the start of my Registry script, or is that too late in
the request?
PerlFixupHandler would be the best place to fixup $r-args
Re: CGI.pm and QUERY_STRING fixup
On Tue, 25 Jan 2000, Bill Moseley wrote: Ok, this seems to work, but perldoc Apache doesn't say anything about setting it. Is this at risk of not working in the future? you can set $r-args, that won't be going away in the future.
Re: Apache::AuthCookie takeover?
On Tue, 25 Jan 2000, Ken Williams wrote: Can someone set the maintainer of Apache::AuthCookie to be me? patch below :) thanks Ken!! diff -u -u -r1.63 apache-modlist.html --- apache-modlist.html 1999/11/24 02:40:01 1.63 +++ apache-modlist.html 2000/01/27 05:19:27 @@ -114,7 +114,7 @@ * PerlAuthenHandler's AuthAnybdpfAuthenticate with any username/password MPB AuthenCachebmpfCache authentication credentialsJBODNAR -AuthCookie bdpOAuthen + Authz via cookies EBARTLEY +AuthCookie bdpOAuthen + Authz via cookies KWILLIAM AuthenDBI bmpOAuthenticate via Perl's DBI MERGL AuthExpire i Expire Basic auth credentials DOUGM AuthenGSS cdpfGeneric Security Service (RFC 2078) DOUGM
Re: self url
On Wed, 26 Jan 2000, Vladimir Ivaschenko wrote: Hello, Is there a way to get the URL of the current document in Embperl? Sort of like $q-self_url in CGI.pm. from chapter 9 of wrapmod: If the URI argument is omitted, the Iparse() method will construct a fully qualified URI from B$r object, including the scheme, hostname, port, path and query string. Example: my $self_uri = Apache::URI-parse($r);
Re: numerous segv's, bus errors
On Wed, 26 Jan 2000, Steven Parkes wrote: We've been getting many segv's and bus errors on apache processes since adding modperl. Env: Apache 1.3.11 (though we had the same thing under 1.3.9.), Perl 5.005003, modperl 1.21, hpux 11.00. At first most of the failures were coming within visit() during what looks to be clean up of children. PerlFreshRestart is Off. I added PerlSetEnv PERL_DESTRUCT_LEVEL -1 and that seemed to get rid of many of those though this seems like a less than optimal solution and I'd like to better understand what the real issue is here. Moreover, we still see a number of failures. Many seem to occur in __errno. (gdb) bt #0 0xc01ecb88 in kill () from /usr/lib/libc.2 #1 0x769c8 in sig_coredump () from /usr/local/alpha/apache/bin/httpd #2 signal handler called #3 0xc0179214 in __errno () from /usr/lib/libc.2 #4 0xc01751bc in free () from /usr/lib/libc.2 #5 0x10013c in Perl_safefree () from /usr/local/alpha/apache/bin/httpd #6 0x112248 in Perl_sv_clear () from /usr/local/alpha/apache/bin/httpd #7 0x112478 in Perl_sv_free () from /usr/local/alpha/apache/bin/httpd a buggy xs modules or c library that overwrites memory can trigger these problems, seemingly random core dumps in free() or malloc(). do you have a tool such as purify or insure? they can often identify the problem right away. otherwise, we need to know more about your setup to help, what modules you're using, etc.
Re: Results of calling perl_shutdown in mp_dso_unload
On Wed, 26 Jan 2000, Daniel Jacobowitz wrote: Here's a question - an apache patch should be able to mark the module as not-to-unload (although since it should be not-to-unload-unless-removed-from-config it would be a bit more complicated than that - still not impossible). But is that worthwhile or should we just adjust to being unloaded if built as DSO? I think both options would be nice to have. Which reminds me - the CVS instructions linked from perl.apache.org no longer work. Is there a public CVS archive still? Where did it move? things have changed recently, here's a snippet from the latest mod_perl_cvs.pod: =item anoncvs To checkout a fresh copy from anoncvs use cvs -d "pserver:[EMAIL PROTECTED]:/home/cvspublic" login with the password "anoncvs". cvs -d "pserver:[EMAIL PROTECTED]:/home/cvspublic" co modperl For a basic introduction to anoncvs see http://dev.apache.org/anoncvs.txt
RE: Proxy example in eagle book does not work
On Wed, 19 Jan 2000, Jonas Nordström wrote:
I had the same problem. What does the "1" mean? That the sub returns with a
true value?
yes, from ch9:
=item do()
This method provides a way to iterate through an entire table item by
item. Pass it a reference to a code subroutine to be called once for
each table entry. The subroutine should accept two arguments
corresponding to the key and value respectively, and should return a
true value. The routine can return a false value to terminate the
iteration prematurely.
This example dumps the contents of the Iheaders_in field to the
browser:
$r-headers_in-do(sub {
my($key, $value) = @_;
$r-print("$key = $value\n");
1;
});
For another example of Ido(), see listing 7.12 from the previous
chapter, where we use it to transfer the incoming headers from
the incoming Apache request to an outgoing LWP IHTTP::Request
object.
---
which means, ch7's example is broken, or that $request-header returned a
true value when the example was written. I suppose the ch7 example should
explictly return 1 regardless.
Re: [ID 20000118.004] DynaLoader doesn't dlclose XS code on interpreter
Unfortunately I can't actually get mod_perl + a load of other stuff to build on 5.005_63, so I can't see if it cures the mod_perl problem. you need modperl from cvs to use 5.005_62+ http://perl.apache.org/from-cvs/ Could a DynaLoader guru have a quick look at the patch and let me know if it is complete garbage? I have backported the patch to 5.005_03, and it appears that mod_perl doesn't actually destroy the perl interpreter correctly when Apache does a restart. this wasn't a mistake at the time. there was no Apache dso and perl_destruct() was buggy, so mod_perl chose to only boot the interpreter once at startup and restarts became a noop for mod_perl, with the exception of "PerlFreshRestart", which just reloads %INC and flushes the Apache::Registry cache. I plan to revisit that along with the patches sometime within the next few days.
Re: Attempt to free unreferenced scalar during global destruction.
On Thu, 4 Nov 1999, Andrei A. Voropaev wrote: Hi! For some reason I get lots of 'Attempt to free unreferenced scalar during global destruction.' in my error log. Any one can give me a pointer where to search for the problem? it's most likely due to a buggy xs module. that message will only show up during child_exit, it probably isn't cause for alarm. how often do you see the message? what xs modules do you have loaded?
Re: SegFaults caused by Apache::Cookie during ChildExit
On Wed, 22 Dec 1999, Clinton Gormley wrote: I am using a home-baked session manager on my web site. I clean up expired sessions by called a child exit handlder and this all worked rather well. However, we have recompiled Perl, Apache, mod_perl and Perl modules with pgcc and a different configuration (removed all modules we didn't need), and now I get a SegFault when Apache::Cookie-new is called during a ChildExit. I use Apache::Cookie in Authorization and PerlHandler phases without a problem. Not sure whether this problem is caused by the compiler or the different configuration at compile. Any ideas of starting points? Apache::Cookie needs a request_rec, there is no request_rec during ChildExit. this dependency could probably be loosened, but it won't work with the current version of libapreq.
Re: your mail
On Thu, 23 Dec 1999, Li,Yuan N.(NXI) wrote: I have fought hard quite a few days trying to add mod_perl1.21 onto apache 1.3.9 on HP 11. I use the c compiler comes with the machine, and installed Perl 5.00503 under my home directory /home/c015932/opt/perl(I do not have access to the root), although the host has its own Perl 5.004 installed under /opt/perl5. Everything compiles, the current issue I have is at the link stage. I got the following massage from running make. I guess I either missed something in my library specification or forgot to load some Perl module. Can someone help me pointing out the obvious? Any help will be appreciated. ... -L/usr/local/lib /opt/perl5/lib/PA-RISC2.0/5.00404/auto/DynaLoader/DynaLoader.a -L/home/c015932/opt/perl/lib/5.00503/PA-RISC2.0/CORE -L/home/c015932/opt/perl5.005_03/libperl.a -lperl -lnet -lnsl -lnm -lndbm -ldld -lm -lc -lndir -lcrypt -lm -lpthread /usr/ccs/bin/ld: (Warning) At least one PA 2.0 object file (buildmark.o) was detected. The linked output may not run on a PA 1.x system. /usr/ccs/bin/ld: Unsatisfied symbols: Perl_Sv (data) ... do you have a libperl in /usr/local/lib ? if so, delete it.
Re: a possible bug with Apache::Server::ReStarting
Hi, While documenting the 'restart twice on start' apache's behavior, I've tested $Apache::Server::ReStarting and $Apache::Server::Starting. Perl section is executed twice -- OK. startup.pl is executed once -- OK. $Apache::Server::ReStarting never gets set! - I suppose it's a bug. (I have tried Apache::Server::ReStarting and Apache::ServerReStarting which is the same... I've even tried Apache::Server::Restarting and Apache::ServerRestarting - I know they don't exist) Meanwhile the only workaround is: ReStarting == true if Starting == false Here is the test that you can reproduce: I've added: httpd.conf: -- Perl print STDERR "Perl Apache::Server::Starting is true \n" if $Apache::Server::Starting; print STDERR "Perl Apache::Server::Starting is false \n" unless $Apache::Server::Starting; print STDERR "Perl Apache::Server::ReStarting is true \n" if $Apache::Server::ReStarting; print STDERR "Perl Apache::Server::ReStarting is false \n" unless $Apache::Server::ReStarting; /Perl startup.pl: --- print STDERR "startup.pl: Apache::Server::Starting is true \n" if $Apache::Server::Starting; print STDERR "startup.pl: Apache::Server::Starting is false \n" unless $Apache::Server::Starting; print STDERR "startup.pl: Apache::Server::ReStarting is true \n" if $Apache::Server::ReStarting; print STDERR "startup.pl: Apache::Server::ReStarting is false \n" unless $Apache::Server::ReStarting; when server is started startup.pl: Apache::Server::Starting is true startup.pl: Apache::Server::ReStarting is false Perl Apache::Server::Starting is true Perl Apache::Server::ReStarting is false and in the error_log: Perl Apache::Server::Starting is false Perl Apache::Server::ReStarting is false I'm running the latest CVS (both mod_perl and apache) version on linux with perl5.00503 if it matters. BTW, Doug -- a wish list: I think we need four states: 1. Starting 2. Restarting 3. Running 4. Stopping I needed the 'Stopping' flag for the runwaway processes watchdog if you remember. probably other cleanup and alerting features can be added using the 'stopping' flag. Regarding implementation -- it can be a single variable, with four states. Thanks! ___ Stas Bekmanmailto:[EMAIL PROTECTED] http://www.stason.org/stas Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC perl.apache.orgmodperl.sourcegarden.org perlmonth.comperl.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
Re: send_fd and timeout problem
On Fri, 7 Jan 2000, Martin Lichtin wrote: Hi, I'm using send_fd() to send relatively large files. Apache's Timeout is currently set to 60s and indeed, mod_perl aborts as soon as the minute elapses. (error msg: mod_perl: Apache-print timed out). However, it shouldn't do that, right? As ap_send_fd_length() does 8k chunking and uses a soft timeout, reset for each chunk, I would have expected that it would only abort if it couldn't send 8k within a minute. This would also match Apache's Timeout documentation saying "The amount of time between ACKs on transmissions of TCP packets in responses". mod_perl doesn't set it's own alarm when $r-send_fd is called. did you call $r-print or print before hand?
Re: Perl modules in apache configuration
On Sun, 9 Jan 2000 [EMAIL PROTECTED] wrote:
"Eric" == Eric writes:
Eric On Sun, Jan 09, 2000 at 08:47:04PM +0300, [EMAIL PROTECTED] wrote:
I'm trying to configure httpd.conf using Perl sections (mod_macro is
not enough for me), but the result is weird.
Eric Do you have a specific example of your config, and what doesn't work,
Eric that you could post maybe? It's hard to help without specifics.
Okay, here it is. Note that fragment marked #!!! is critical for some
bugs: when these strings are commented out, first Perl block
executes with error, if they are uncommented, it does NOT
executes. Second Perl block never executes at all.
#!!!
#foreach (keys %$Location{"/$loc"}) {
that should be %Location, not %$Location
if you compile with PERL_TRACE=1 (option to Makefile.PL) and set the
environment variable MOD_PERL_TRACE to all before starting the server,
you'll get some diagnostics that can help debug these situations.
Re: File upload bug in libapreq
On Tue, 11 Jan 2000, Jim Winstead wrote: There appears to be a file upload bug in libapreq that causes httpd processes to spin out of control. There's a mention of this in the mailing list archives with a patch that seems to be a partial solution, but we're still seeing problems even with the patch I've attached. They appear to get stuck in the strstr() call. Anyone tracked this one down before? We haven't had any real luck figuring out what triggers the condition that sends things into a tail-spin, and I admittedly haven't crawled through the code too carefully to see what could be going wrong. do you have a test case I can use to reproduce the strstr() hang bug?
Re: Patch to Apache::RedirectFixLog in mod_perl-1.21
looks good, thanks David!
On Tue, 11 Jan 2000, David D. Kilzer wrote:
Hi,
The patch below fixes a problem in Apache::RedirectFixLog when the URI
being logged required use of a filename listed the DirectoryIndex
directive.
The solution is described in the following post by Doug MacEachern to
the modperl list in 1998.
http://www.geocrawler.com/mail/msg.php3?msg_id=1059028list=182
A similar problem is described in the following thread in 1999 (though
the answer is never realized):
http://www.geocrawler.com/mail/msg.php3?msg_id=2466537list=182
I am not subscribed to modperl. Please Cc: me on any responses.
Thanks!
Dave
--
David D. Kilzer \ ``Follow your dreams, you can reach your goals.
Senior Programmer / I'm living proof. Beefcake. BEEFCAKE!''
E-Markets, Inc. \ Eric Cartman
[EMAIL PROTECTED]/ _South_Park_
diff -u mod_perl-1.21/lib/Apache/RedirectLogFix.pm.orig
mod_perl-1.21/lib/Apache/RedirectLogFix.pm
--- mod_perl-1.21/lib/Apache/RedirectLogFix.pm.orig Wed Aug 12 20:46:26 1998
+++ mod_perl-1.21/lib/Apache/RedirectLogFix.pmTue Jan 11 21:21:08 2000
@@ -3,7 +3,7 @@
use Apache::Constants qw(OK DECLINED REDIRECT);
sub handler {
-my $r = shift;
+my $r = shift-last;
return DECLINED unless $r-handler ($r-handler eq "perl-script");
if(my $loc = $r-header_out("Location")) {
Re: alarm() in Apache::Registry
On Thu, 13 Jan 2000, Bill Moseley wrote:
At 08:50 AM 1/13/00 +0200, you wrote:
Does anyone have experience using an alarm() call under Apache::Registry?
http://perl.apache.org/guide/debug.html#Handling_the_server_timeout_case
Should I set alarm(0) as my script "exits" or is it ok to leave it set?
I'm using it to cap runaway scripts.
Just so I understand the Guide - You can safely localize $SIG{ALRM} in 1.21
and Perl 5.005_03, but not other signal handlers?
are you having trouble with other signals? mod_perl is only trying to
deal with those that cause conflict with Apache's. if you've found one,
add it to the list in perl_config.c:
static char *sigsave[] = { "ALRM", NULL };
does it help?
In:
http://perl.apache.org/guide/debug.html#Debugging_Signal_Handlers_SIG_
The Sys::Signal example is a bit confusing to me, as it uses $SIG{ALRM} in
the example. Yet that seems like the one signal where you don't need to
use Sys::Signal. Was the example of Sys::Signal written before the
$SIG{ALRM} fix?
yes.
Re: Apache::Registry should allow script to _only_ set return code
thanks Charles, I think your patch is the way to go for now, or something
close to it for 1.22
On Thu, 13 Jan 2000, Charles Levert wrote:
Hi.
[ I use Apache 1.3.9 and mod_perl 1.21. ]
I believe that there is a difference between the following two
behaviors for an Apache module handler:
-- setting the request's status field to a new value and also
returning that value;
-- just returning a value without assigning it to the
request's status field.
It's an useful thing that a mod_perl script (what
Apache::Registry::handler calls) be able to decide that, e.g.,
HTTP_NOT_FOUND, should be returned to the browser and just return
then.
# example mod_perl script
use Apache::Constants ':response';
my $r = Apache-request;
if (...) {
$r-status(NOT_FOUND);
return;
}
$r-content_type('text/html');
...
We then expect that the normal ErrorDocument, as configured, should be
returned in that case. However, this is not what happens because
Apache::Registry chooses the first behavior listed above and so an
HTTP_NOT_FOUND also seems to apply to the ErrorDocument then. (This
is what Apache reports to the browser.) The useful behavior would be
the second one listed above.
Ideally, a method such as $r-return_value could be defined,
independently of $r-status, and its argument could then be used when
Apache::Registry::handler returns. An other possibility which can
probably be ruled out for compatibily with CGI scripts and existing
mod_perl script is to use the return value from the mod_perl script
itself.
I have appended a patch to Apache::Registry below which I believe to
be an acceptable solution for now. (It really disallows a script to
set the status field, but uses the possibly changed status field as
return value instead and resets the status field to its original
value.)
Your comments are welcome. Do you think that such a change or what I
mention above ($r-return_value) should make it in the main
distribution of mod_perl?
Charles
--- Registry.pm.orig-1.21 Tue Jan 12 21:56:34 1999
+++ Registry.pm Thu Jan 13 16:11:23 2000
@@ -131,6 +131,8 @@
$Apache::Registry-{$package}{'mtime'} = $mtime;
}
+ my $old_status = $r-status;
+
my $cv = \{"$package\::handler"};
eval { {$cv}($r, @_) } if $r-seqno;
$r-chdir_file("$Apache::Server::CWD/");
@@ -155,7 +157,7 @@
#return REDIRECT;
#}
#}
- return $r-status;
+ return $r-status($old_status);
} else {
return NOT_FOUND unless $Debug $Debug 2;
return Apache::Debug::dump($r, NOT_FOUND);
Re: Proxy example in eagle book does not work
On Fri, 14 Jan 2000, Jason Bodnar wrote:
A line in the proxy example of the eagle book on page 380 does not seem to work
(entirely):
The line:
$r-headers_in-do(sub {$request-header(@_);});
what if you change that to:
$r-headers_in-do(sub {$request-header(@_); 1});
?
Re: a possible bug with Apache::Server::ReStarting
On Wed, 19 Jan 2000, Stas Bekman wrote:
Why? Some users need a control of what gets reloaded and what not on
server start (Yes I know if you put in startup.pl file it loads only once)
For example parsing and loading some heavy xml files...
Why do you want to take it away?
I think PerlRestartHandler is a better solution in most cases. and inside
Perl sections you can always do it on your own:
Perl
do_something() unless $My::Init++
/Perl
I'm cringing at global variables in general looking forwared to threaded
2.0. do you have a concrete example that requires
$Apache::Server::{Starting,ReStarting} ?
Re: [PATCH] Compiling mod_perl with ActivePerl
On Tue, 7 Sep 1999, Jochen Wiedmann wrote: Hi, attached you find a somewhat larger patch as a first step in order to get mod_perl running with ActivePerl. This is mainly to get the public source tree in sync with my work: I am still far away from getting it running. What I did so far is eliminate compiler problems, except for about 5 or 6 compiler errors that seem somewhat deeper. sorry for the looong delay, I have applied your patch to the cvs tree. however, I have no way to test ActivePerl or vanilla win32 at the moment.
Re: Read query string on POST request?
On Thu, 16 Dec 1999, Tobias Hoellrich wrote:
I pass a session id in the query string between invocations for my
current project (only if the client does not support Cookies). My main
handler is also responsible for creating an Apache::Request object right
at the beginnig of the handler invocation. sub components rely on the
information found in the $apr object.
For GET's everything is fine, for POSTs the Apache::Request-new will
not look at the query string, because it is a POST. Fine.
that's strange, it's supposed to parse both, see apache_request.c :
int ApacheRequest_parse_urlencoded(ApacheRequest *req)
{
request_rec *r = req-r;
int rc = OK;
if (r-method_number == M_POST) {
... parse POST body ...
}
if (r-args) {
... parse query string ...
}
return OK;
}
do you have a tiny case I can try?
Re: broken USE_APXS (was Re: Apache::Scoreboard - problem compiling)
Anyone using USE_APXS has any ideas of why USE_APXS makes the installation incomplete? fixed now in cvs.
Re: Problems with dynamically-loaded perl modules under Solaris2.5.1
On Thu, 16 Dec 1999, Dan Rench wrote: On Mon, 13 Dec 1999, Doug MacEachern wrote: are you still stuck on this? Yes. To reiterate: Solaris 2.5.1 sparc, gcc 2.95, perl 5.005_03 (configured with Solaris hints), mod_perl 1.21, apache 1.3.9, mod_fastcgi 2.2.2. Everything works fine EXCEPT when I try to "use" a dynamically loaded module (Data::Dumper or Storable, for example) inside a mod_perl handler. I have no trouble using these modules in regular perl scripts, mod_cgi scripts, or mod_fastcgi scripts. this sounds an awful lot like the common solaris linker vs. gnu linker problem. what does 'perl -V:ld' say your linker is? make sure it's gnu (gcc) and that Apache is using the same.
Re: Another install question: CGI.pm not found
On Thu, 16 Dec 1999, Bill Moseley wrote: What obvious thing am I missing? During make test this gets written to the error log: Can't locate CGI.pm in @INC at /mod_perl-1.21/t/net/perl/cgi.pl line 7. that's a strange error, because 5.005+ reports the @INC paths, e.g.: % perl -MNotHere Can't locate NotHere.pm in @INC (@INC contains: /usr/local/devperl/lib/5.00563/i686-linux /usr/local/devperl/lib/5.00563 /usr/local/devperl/lib/site_perl/5.00563/i686-linux /usr/local/devperl/lib/site_perl .). BEGIN failed--compilation aborted. maybe you're picking up an old perl in your path somehow?
Re: PerlModule/Require didn't work ??
On Thu, 16 Dec 1999 [EMAIL PROTECTED] wrote: hi, I was wondering why the PerlModule and perlRequire didn't work for me. I have a fresh installation of : apache 1.3.9 + mod_perl 1.21 (that is bundled in RedHat6.1), what was my surprise to see that when I try to use something like : PerlRequire .../startup.pl or PerlModule Apache::DBI Apache::ASP the Apache won't start. When I start the apache i.e. : /etc/rc.d/init.d/httpd start I get .. [OK] , but nothing started nothing even in the error_log :"( (LogLevel debug). I missed something or WHAT ?!? there have been several messages over the past 1-2 weeks on how to diagnose the problem, did you try any of them? I thought that it was 'cause now by default if Apache find suEXEC it runs in suEXEC-mode, but I moved suEXEC and it dosen't use it then. Another surprice was that if I go .../perl-status .. Loaded Modules ... I see CGI there, but I didn't point to it in .conf files.?!?! Apache::Status uses CGI.pm, or Apache::Request if you have it installed.
Re: Another install question: CGI.pm not found
79) %grep cgi.pl t/logs/error_log Can't locate CGI.pm in @INC at /data/_g/lii/apache/src/heavy/mod_perl-1.21/t/net/perl/cgi.pl line 3. again, I don't think it's possible for 5.005+ to produce this error message without listing the contents of @INC. cgi.pl is generated from cgi.pl.PL and also tested under mod_cgi, have a look, maybe the #!/.../perl line is wrong?
Re: [Re: [Re: again - more then one PerlTransHandler]]
At least that's what I thought ! In fact now Apache lets me use more then one PerlTransHandler, but it doesn't care of what is the return codes are!!! Even I return OK, it still calls next registered handlers. Really weird! mod_perl does care. but, mod_perl stacked handlers are not quite the same as Apache C handlers. unless the return status from a Perl handler is something other than OK or DECLINED, mod_perl propagates the status code of the last handler run back up to Apache. originally, stacked handlers were introduced for chaining multiple content handlers. if the OK status from the first handler was propagated back to Apache, there would be no chain, and little use for stacked handlers. you can always override this behavior by using a single Perl*Handler which decides what path to take based on the return status, or use a PerlDispatchHandler, or PerlDirectiveHandlers, to name a few.
Re: Problem running LWP under modperl (LONG)
On Tue, 21 Dec 1999, Barry Hoggard wrote: I can't get LWP::UserAgent to run correctly under modperl, but I can make it work from the command line or as a regular CGI. strange, works fine here. }, 'HTTP::Headers' ), '_rc' = 500, '_msg' = 'Can\'t call method "new" without a package or object reference' }, 'HTTP::Response' ); 500 (Internal Server Error) Can't call method "new" without a package or object reference Client-Date: Tue, 21 Dec 1999 17:46:19 GMT - The line where it dies is here (warnings added by me) in LWP::Protocol::http. I never get the second warning under Registry. warn "CREATING SELECT with $socket"; my $sel = IO::Select-new($socket) if $timeout; warn "SELECT CREATED"; hmm, any difference if you add 'PerlModule IO::Select' to httpd.conf?
Re: Core dump on graceful restart.
(gdb) where #0 0x80f4d4b in do_clean_objs () #1 0x80f4ccf in visit () #2 0x80f4df2 in Perl_sv_clean_objs () #3 0x80c2418 in perl_destruct () #4 0x8062920 in perl_shutdown () #5 0x8063aee in perl_child_exit () do you create any global objects that don't go out of scope until the server exits? one that need to have their DESTROY method called for cleaning things up the os won't? if not, you can bandaid by setting the environment variable PERL_DESTRUCT_LEVEL to -1, then mod_perl will skip the call to perl_destruct(). can you reproduce this simply by starting the server and doing a graceful restart, without serving any requests? what modules are you preloading?
Re: Hanging processes [LONG with debugging output]
(gdb) perl_get_sv("Apache::Constants::AUTOLOAD")
Apache::Constants::OPT_EXECCGI
what I was about to suggest trying is already in the modperl cvs Changes:
preload Apache::Constants::OPT_EXECCGI() for Apache::{Registry,PerlRun}
thanks to Chris Remshaw for spotting this w/ Apache::DProf
so try the cvs snapshot, or in a PerlRequire file, preload it like so:
Apache::Constants::OPT_EXECCGI();
Re: mod_perl 1.21 - CGI.pm 2.56 error in phase other than content
On Fri, 10 Dec 1999 [EMAIL PROTECTED] wrote:
Does nay one know how to get round the bug in the above combination. When I
create a new CGI in any phase other than Response I get a Can't call method
"register_cleanup" on an undefined value at /usr/lib/perl5/5.00505/CGI.pm
line 263.
This would appear to be caused by apache-request not returning the request.
from ~/Mail/.sent-mail-sep-1999:
To: Ken Williams [EMAIL PROTECTED]
cc: al [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Help! CGI.pm problems with Apache
In-Reply-To: [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 3 Aug 1999, Ken Williams wrote:
I believe you need to upgrade your mod_perl, this bug has been squashed in
1.21.
this is actually not related to that bug. the bug 1.21 fixed what that
registered cleanups were not always called. this bug is triggered by
CGI.pm calling Apache-request before the content response phase. Ali,
give us more details on your module, what phase is it called in? you
should be able to bandaid with this configuration:
PerlPostReadRequestHandler 'sub { Apache-request(shift) }'
-Doug
Re: silent failure when I try to use PerlRequire in httpd.conf
if you build with PERL_TRACE=1 and start the server like so: % setenv MOD_PERL_TRACE=1 % httpd -X you should get some helpful diagnotics. On Sat, 11 Dec 1999, Bill Marrs wrote: Hi, I've been using mod_perl successfully albeit minimally for a couple months now. I'm trying to tune performance and memory usage by consolidating some common Perl "use" directives in a PerlRequire statement. However, when I add this line to my Apache config file (/etc/httpd/conf/httpd.conf), the server fails to come up - and also give no indication that I can find of a problem. So, I don't know what's going wrong. Here's what I'm adding to my httpd.conf file: PerlRequire /home/ugtz/startup.pl I have the usual stuff in my /home/ugtz/startup.pl file, actually I tried commenting everything but the #!/usr/local/bin/perl and the "1;" at the end, and it still failed. So, I don't think the contents of the file are at fault. My httpd error log doesn't say anything is wrong, it actually doesn't log anything - like it never got that far... I do: % /etc/rc.d/init.d/httpd start Starting httpd: [ OK ] % ps -ef |grep httpd [no httpd processes] % tail /etc/httpd/logs/error_log [ nothing new in log ] Does anyone have any clues for me to track down on this, I'm stumped. -bill
Re: more then one PerlTransHandler
On 12 Dec 1999, Evgenii Bazarov wrote: Hi! I tried to set more then one PerlTransHandler but if I specify both on the same line, Apache says "syntax error", otherwise it see only the last one. make sure you have built the server with at least PERL_STACKED_HANDLERS=1 or EVERYTHING=1. if you're still stuck, please send the complete error message.
Re: Newbie: Tough times with sfio
On Sun, 5 Dec 1999, hamid khoshnevis wrote: Hello, I am a newbie modperl'er and I am tyring to get system calls to return data to modperl (via stdout). Based on what I have read, sfio need to be linked in. Has anyone successfully done so and does stdout gets directed properly. you can use: print `command`; instead of system "command"; but you're throwing performance out the window either way. best not to fork at all if you can avoid it.
Re: simple xml parsing within html
On Thu, 9 Dec 1999, G.W. Haywood wrote: any suggestions on making HTML::Parser work faster Performance is a real issue in mod_perl systems, so I've put some work into this. Maybe it will spawn a thread. Here are a couple of suggestions for speeding up HTML::Parser. Apparently the author is looking at this at present too. He will know a lot more about what the code is doing that I do. have you not seen HTML-Parser-XS: http://www.cpan.org/authors/id/GAAS/ ??
Re: Unloading a library
On Tue, 7 Dec 1999, Matt Sergeant wrote:
How can I completely unload a library and all memory associated with it,
and unload any dso's connected with that library? For example, say I use
XML::Parser in a Perl section - I don't want that hanging around - it's a
big library, so I'd like to completely unload it - is it possible?
how about:
delete $INC{'XML/Parser.pm'};
Apache::PerlRun-flush_namespace('XML::Parser');
for .so's you might be able to pull some stunts with DynaLoader, but I
haven't tried that.
Re: PerlFreshRestart and %INC
On Fri, 3 Dec 1999, Tim Bunce wrote: ... But is that _really_ what PerlFreshRestart does? I thought it destroyed the entire perl interpreter before then recreating one from scratch? this is the way PerlFreshRestart works at the moment. the original implementation did destroy the interpreter and re-compile everything from scratch. but perl_destruct() wasn't quite bug free at the time, the current hack was put in it's place, which we found out later, isn't bug free either. we will do it the right way for 2.0, but in the meantime, a complete shutdown and start of the server is the safest way to do a "fresh restart".
Re: Apache::StatINC problem with use base
On Sun, 5 Dec 1999, Autarch wrote:
I encountered a problem using Apache::StatINC with modules that have the
directive:
use base qw( SomeClass );
The error I got was the following:
[Mon Dec 6 07:35:47 1999] [error] Inherited %FIELDS can't override existing %FIELDS
at /usr/lib/perl5/5.0050 3/base.pm line 73
BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.005/HKMDB/Job.pm
line 10.
After messing a bit with Apache::StatINC I found that the solution was to
'use' the module again rather than requiring it.
I have a patch attached to do this. I'm not sure if this is really the
right solution though.
! require $key;
...
! eval "use $key;";
use() doesn't help, you just hid the problem with eval ""
I suppose it wouldn't be such a bad idea to change:
eval { require $key };
warn $@ if $@;
Re: Name: overview
On Sat, 4 Dec 1999, Victor Zamouline wrote: Let me overview the propositions that have been made: 1) Eagle, proposed by Ged Haywood. Copyrighted by O'Reilly, but it looks like this problem can be solved. 2) Hedgehog, proposed by Stas Bekman. 3) Oyster, proposed by Randy Harmon 4) Mythical beast with the head of an eagle and the body of a camel, proposed by Rod Butcher 5) Meld Pro, anagram proposed by Robin Berjon 6) Eagle with a single red-blue-yellow feather in its wing, proposed by Salve Nilsen 7) Red brick base of a building, with mod_perl inscribed on a brass plaque, proposed by John Burns Did I miss out something? while I appreciate the enthusiasm: - the name mod_perl will not change, mod_ == Apache, perl == Perl, the name is almost 4 years old, it simply doesn't make sense to change it - if you want to hold a new logo contest like the one we had ~2 years ago, that could be fun, see http://perl.apache.org/logos/
Re: Book: guestbook.cgi
On Sun, 12 Dec 1999, Michael Dearman wrote: I've copied example 4-15 and multi-checked it, for the past couple of days. Finally used a copy of the example obtained from the book site. But still have problems. modperl.com has the book source tarball, including a newer version of the guestbook than the (broken) example in the book.
Re: @INC and make test
looks like the httpd you are running does not have Apache::Util linked in.
EVERYTHING=1 should take care of that, which you can see using nm:
% nm ../apache-1.3/src/httpd | grep Util
0809b800 T XS_Apache__Util_escape_html
0809b750 T XS_Apache__Util_escape_uri
0809b8a0 T XS_Apache__Util_ht_time
0809b9e0 T XS_Apache__Util_parsedate
0809b6c4 T XS_Apache__Util_size_string
0809ba94 T boot_Apache__Util
On Wed, 8 Dec 1999, Ruben I Safir wrote:
Working on Red HAT 6.0
Down loaded and untarred Perl Modules and Apache
(no rpm)
make test on modperl fails on trying to find PerlTransHandler which
httpd -L doesn't display.
Compilered according to instructions for APACI with
perl Makefile.PL EVERYTHING=1 DO_HTTPD=1 USE_APACI-1
make
make install
Also - we loaded EMBPERL. We are using the following httpd.conf listing
on the bottom.
httpd can't load a modules Apache:Util which is in the path that it says
it can't find.
This is the error:
[root@webbie /root]#
/usr/local/apache/bin/httpd
Syntax error on line 198 of /usr/local/apache/conf/httpd.conf:
Can't locate loadable object for module Apache::Util in @INC (@INC
contains: /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503
/usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005
. /usr/local/apache/ /usr/local/apache/lib/perl) at
/usr/lib/perl5/site_perl/5.005/i386-linux/mod_perl.pm line 14
BEGIN failed--compilation aborted at
/usr/lib/perl5/site_perl/5.005/Apache/EmbperlChain.pm line 4.
ls -al /usr/lib/perl5/site_perl/5.005/i386-linux/Apache
Blah Blah
-rwxrwxrwx 1 root root 2444 Feb 1 1999 Util.pm
As you can see, I opened Util all the way, yet it still can't seem to be
found (grinding teeth)
I tried to uncover the error but I think I'm not getting the problem.
I modified mod_perl.pm to printout from standard error
The result is this:
[root@webbie /root]# /usr/local/apache/bin/httpd
ENV mod_perl/1.21 CLASS : Apache::Constants
ENV mod_perl/1.21 CLASS : Apache::Connection
ENV mod_perl/1.21 CLASS : Apache::Server
ENV mod_perl/1.21 CLASS : Apache
ENV mod_perl/1.21 CLASS : Apache::Util
Syntax error on line 198 of /usr/local/apache/conf/httpd.conf:
Can't locate loadable object for module Apache::Util in @INC (@INC
contains: /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503
/usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005
. /usr/local/apache/ /usr/local/apache/lib/perl) at
/usr/lib/perl5/site_perl/5.005/i386-linux/mod_perl.pm line 17
BEGIN failed--compilation aborted at
/usr/lib/perl5/site_perl/5.005/Apache/EmbperlChain.pm line 4.
__
ServerType standalone
ServerRoot "/usr/local/apache"
PidFile /usr/local/apache/logs/httpd.pid
ScoreBoardFile /usr/local/apache/logs/httpd.scoreboard
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
MinSpareServers 5
MaxSpareServers 10
StartServers 5
MaxClients 150
MaxRequestsPerChild 0
Port 80
User nobody
Group nobody
ServerAdmin [EMAIL PROTECTED]
DocumentRoot "/usr/local/apache/htdocs"
Directory /
Options FollowSymLinks
AllowOverride None
/Directory
Directory "/usr/local/apache/htdocs"
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
/Directory
UserDir public_html
DirectoryIndex index.html
AccessFileName .htaccess
Files ~ "^\.ht"
Order allow,deny
Deny from all
/Files
UseCanonicalName On
TypesConfig /usr/local/apache/conf/mime.types
DefaultType text/plain
IfModule mod_mime_magic.c
MIMEMagicFile /usr/local/apache/conf/magic
/IfModule
HostnameLookups Off
ErrorLog /usr/local/apache/logs/error_log
LogLevel warn
LogFormat "%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-Agent}i\""
combined
LogFormat "%h %l %u %t \"%r\" %s %b" common
LogFormat "%{Referer}i - %U" referer
LogFormat "%{User-agent}i" agent
CustomLog /usr/local/apache/logs/access_log common
ServerSignature On
Alias /icons/ "/usr/local/apache/icons/"
Alias /embperl2 "/usr/local/apache/embperl/"
Directory "/usr/local/apache/icons"
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
/Directory
# This module changes base href to sruben.dental.nyu.edu
PerlModule Apache::BASEREF
Directory "/usr/local/apache/htdocs"
SetHandler perl-script
PerlHandler Apache::BASEREF
/Directory
Directory "/usr/local/apache/embperl"
SetHandler perl-script
PerlHandler Apache::BASEREF
/Directory
Directory "/usr/local/apache/finance"
SetHandler perl-script
PerlHandler Apache::BASEREF
/Directory
ScriptAlias /cgi-bin/ "/usr/local/apache/cgi-bin/"
Directory "/usr/local/apache/cgi-bin"
AllowOverride None
Re: Hanging processes
On Fri, 10 Dec 1999, Tony Demark wrote:
I am having a problem with hanging httpd processes. I have done some AV
searches as well as investigated the list archives and did not find any
conclusive answer to this problem. If I missed it, can someone point me in the
right direction? If any more information will help decode this problem, I can
reproduce the problem really easily (bot hitting our stage site causes a few
of these processes to pop up).
a few things could shed some more light:
build a libperld.a and compile with PERL_DEBUG=1 (see SUPPORT doc)
and/or, in gdb:
(gdb) source mod_perl-1.21/.gdbinit
(gdb) curinfo
should tell you the line/filename of the offending Perl code
add this to the .gdbinit (which is in the modperl cvs tree):
define longmess
set $sv = perl_eval_pv("Carp::longmess()", 1)
printf "%s\n", ((XPV*) ($sv)-sv_any )-xpv_pv
end
(gdb) longmess
should produce a Perl stacktrace
Re: silent failure when I try to use PerlRequire in httpd.conf
#1 0x403da306 in ?? () from /etc/httpd/modules/libperl.so broken record mod_perl+dso is not a stable mix, try linking mod_perl static /broken record
Re: Hanging processes
On Tue, 14 Dec 1999, Tony Demark wrote: Doug, Tried what you suggest, but with seemingly disappointing results. (below) The hangs seem to come _after_ the logging phase - the heap just keep growing and the process takes up all available CPU, but it doesn't seem to be doing anything! if you could try the libperld.a+PERL_DEBUG=1 suggestion, and a new stacktrace, it might provide some new clues.
Re: troubleshooting seg fault/child exit
[Tue Dec 14 15:44:22 1999] [notice] child pid 13243 exit signal Segmentation fault (11) -- ... If someone could please point me in the right direction or FAQ, I, and my sanity, would be most happy. there are quite a few tips on debugging core dumps posted between last night and today, along with the SUPPORT doc. trying building a libperld.a, build mod_perl with PERL_DEBUG=1, and post a stacktrace.
