Can't upgrade that kind of scalar ...

[Doug MacEachern]

fyi...

Index: Changes
===
RCS file: /home/cvs/modperl/Changes,v
retrieving revision 1.445
diff -u -u -r1.445 Changes
--- Changes 2000/03/30 00:44:39 1.445
+++ Changes 2000/03/30 19:35:12
@@ -10,6 +10,11 @@
 
 =item 1.22_01-dev
 
+reset the stack pointer after calling perl_require_module() in
+perl_call_handler().  this fix will most likely cure the reports of
+"Can't upgrade that kind of scalar at ..."
+[Ben Cottrell <[EMAIL PROTECTED]>]
+
 workaround use of Perl api functions that are no longer public with
 Perl 5.6.0 + win32, thanks to Randy Kobes for spotting
 
Index: src/modules/perl/mod_perl.c
===
RCS file: /home/cvs/modperl/src/modules/perl/mod_perl.c,v
retrieving revision 1.110
diff -u -u -r1.110 mod_perl.c
--- src/modules/perl/mod_perl.c 2000/03/30 19:34:13 1.110
+++ src/modules/perl/mod_perl.c 2000/03/30 19:35:25
@@ -1557,6 +1557,7 @@
if(stash) /* check again */
is_method = perl_handler_ismethod(stash, method);
 #endif
+   SPAGAIN; /* reset stack pointer after require() */
}

if(!is_method && !defined_sub) {

Re: Can't locate object method "OPEN" via package "Apache"

[Doug MacEachern]

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: [make test warns] mod_perl/mod_ssl

[Doug MacEachern]

> httpd.conf should have:
> 
> 
> SSLDisable
> SSLSessionCache none
> 

ok, applied, thanks!

Re: Error in Installation

[Doug MacEachern]

On Wed, 29 Mar 2000, Ramesh Vadlapatla wrote:
> ** A test compilation with your Makefile configuration
> ** failed.  The below error output from the compilation
> ** test will give you an idea what is failing. Note that
> ** Apache requires an ANSI C Compiler, such as gcc. 

can you compile apache without mod_perl?  did you use the same compiler to
build both Perl and Apache?

Re: getting mod_perl working

[Doug MacEachern]

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.
>  '   You're mad.
> 

Re: [Patch] Apache::DB on Win32

[Doug MacEachern]

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: [PATCH 5.6.0] local $SIG{FOO} restoration

[Doug MacEachern]

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: Modperl 1.22 and Perl 5.6.0

[Doug MacEachern]

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: Problem Compiling with Perl 5.6.0

[Doug MacEachern]

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: [PATCH 5.6.0] local $SIG{FOO} restoration

[Doug MacEachern]

take2: the first patch did not restore SIG_DFL (when sigstate == 0)

--- mg.c~   Sat Mar 18 19:41:03 2000
+++ mg.cTue Mar 28 23:36:32 2000
@@ -966,8 +966,10 @@
/* cache state so we don't fetch it again */
if(sigstate == SIG_IGN)
sv_setpv(sv,"IGNORE");
-   else
-   sv_setsv(sv,&PL_sv_undef);
+   else if (sigstate)
+   sv_setiv(sv,(IV)sigstate);
+   else
+   sv_setsv(sv, &PL_sv_undef);
PL_psig_ptr[i] = SvREFCNT_inc(sv);
SvTEMP_off(sv);
}
@@ -1002,6 +1004,7 @@
 I32 i;
 SV** svp;
 STRLEN len;
+Sighandler_t sigstate = 0;
 
 s = MgPV(mg,len);
 if (*s == '_') {
@@ -1038,16 +1041,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;
 }

[PATCH 5.6.0] local $SIG{FOO} restoration

[Doug MacEachern]

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;
 }

Re: possible bug: mod_perl 1.22 (Perl 5.6 / Apache 1.3.12)

[Doug MacEachern]

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!

Re: Signal Abort

[Doug MacEachern]

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: why can not test, but can run

[Doug MacEachern]

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: perl 5.6/mod_perl 1.22/apache 1.3.12

[Doug MacEachern]

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 'require' required?

[Doug MacEachern]

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: More segfault problems

[Doug MacEachern]

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: Modperl 1.22 and Perl 5.6.0

[Doug MacEachern]

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: Re-coding some noddy routines in C

[Doug MacEachern]

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: [patch] mod_perl-1.22 and SGI_BOOST

[Doug MacEachern]

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: [ANNOUNCE] mod_perl-1.22

[Doug MacEachern]

On Thu, 23 Mar 2000, Ruben I Safir wrote:

> Is there any security issues forcing an upgrade?

no.

Re: [ANNOUNCE] mod_perl-1.22

[Doug MacEachern]

On Thu, 23 Mar 2000, Oleg Bartunov wrote:
> apxs:Error: /usr/local/apache/bin/httpd not found or not executable
> Writing Makefile for Apache
> apxs:Error: /usr/local/apache/bin/httpd not found or not executable
> Writing Makefile for Apache::Connection

this is fixed now in the cvs tree.

Re: Q: PerlSendHeader

[Doug MacEachern]

On Thu, 23 Mar 2000, Jaime Teng wrote:

> Hi,
> 
> Is there a setting that changes what mod_perl prints when 
> the "PerlSendHeader On" is used?

no, with 'PerlSendHeader On', mod_perl feeds headers into $r->headers_out,
then calls ap_send_http_header(), much like mod_cgi does.
ap_send_http_headers() is hardwired to send certain headers, such as
Server:, Connection:, etc., see http_protocol.c
 
> for whatever reasons, my scripts are not being accepted by 
> some browsers simply because mod_perl is sending some 
> unknown/unsupported headers.
> 
> One of these header is the "Connection: close".

eh?  this is standard http/1.1, even if the browser doesn't understand it,
it should just ignore it.  please describe what you mean by 'not being
accepted'?

[ANNOUNCE] mod_perl-1.22

[Doug MacEachern]

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

[Doug MacEachern]

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
 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]

[ANNOUNCE] mod_perl-1.21_02

[Doug MacEachern]

The URL

http://perl.apache.org/dist/mod_perl-1.21_02.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/DOUGM/mod_perl-1.21_02.tar.gz
  size: 342233 bytes
   md5: fcb243aed6c7ce25a380850f2ce54c0c

i was tempted to call this 1.22 before leaving for apachecon, but i'd like
to give it at least a few more days to see if any issues pop up.

Changes since 1.21_01:

fix Makefile.PL if $USE_APXS && $PERL_DEBUG
[Daniel Jacobowitz <[EMAIL PROTECTED]>]

force environ[] to be copied before any Perl code is loaded
[Daniel Jacobowitz <[EMAIL PROTECTED]>]

localize $_ in Apache::send_cgi_header
[Roderick Schertler <[EMAIL PROTECTED]>]

fix precedence problem in StatINC.pm
[Roderick Schertler <[EMAIL PROTECTED]>]

if hash value has magicalness in , invoke FETCH
thanks to Kevin Ruscoe for the spot

sync with 1.3.12's virtual_host section logic for httpd -S + 
thanks to Kevin Ruscoe for the spot

remove t/httpd symlink during 'make realclean' and when rebuilding
[Geoffrey Young <[EMAIL PROTECTED]>]

add Apache::src::otherldflags method
[Jens-Uwe Mager <[EMAIL PROTECTED]>]

backout modules/util validate_password tests, not everybody has crypt,
thanks to Randy Kobes and Ed Loehr for spotting

fix _AIX typo in dso_unload
[Jens-Uwe Mager <[EMAIL PROTECTED]>]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANNOUNCE: mod_perl-1.21_01]

[Doug MacEachern]

The URL

http://perl.apache.org/dist/mod_perl-1.21_01.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/DOUGM/mod_perl-1.21_01.tar.gz
  size: 344456 bytes
   md5: 0b09fd1768a8a102aa01b07045f9dd84

this release has just about everything planned for 1.22, what it really
needs it testing.  if some folks could take a few moments to run 'make
test', i'd very much appreciate hearing results, thanks!
please include:
perl -V and Makefile.PL options

Changes since 1.21:

#ifdef _AIX, make sure Perl's dlclose is used, instead of Apache's
during dso_unload [Jens-Uwe Mager <[EMAIL PROTECTED]>]

__THE__ dso fix: dlclose() xs shared objects and call perl_shutdown()
before mod_perl's libperl.so is unloaded/reloaded by mod_so
[Daniel Jacobowitz <[EMAIL PROTECTED]>, Alan Burlison <[EMAIL PROTECTED]>]

add  /D "_MSWSOCK_" to ApacheModulePerl.dsp
[Randy Kobes <[EMAIL PROTECTED]>]

removed modules/sandwich test

Apache::RegistryBB returns DECLINED instead of FORBIDDEN if -d $r->finfo
[Sean Chittenden <[EMAIL PROTECTED]>]

add Apache::Util::validate_password(), as suggested by Christophe
Labouisse

call (void)perl_request_rec(r) asap, instead of waiting till the
response phase, e.g. so CGI.pm can be used before PerlHandler, without 
having to call Apache->request($r);

Apache::perl_hook() fixes for Perl*Api, thanks to Geoffrey Young for
the spot

save/restore $^W in Apache::PerlRun
[Honza Pazdziora <[EMAIL PROTECTED]>]

fix Apache::Registry when $r->uri ends with a /
[Peter Deister <[EMAIL PROTECTED]>]

add virtualhost support to Apache::RegistryLoader
[John Hughes <[EMAIL PROTECTED]>]

$Apache::Registry::NameWithVirtualHost fix
[John Hughes <[EMAIL PROTECTED]>]

allow Apache::PerlRun::handler to be subclassed
[Yasushi Nakajima <[EMAIL PROTECTED]>]

fix $r->connection->remote_ip for SGI performance patches (#ifdef SGI_BOOST)
[Artem Veremey <[EMAIL PROTECTED]>]

mod_perl.exp is now installed

aix tweaks for building with apxs
[Jens-Uwe Mager <[EMAIL PROTECTED]>]

pod fixups to avoid WARNING from newer pod2*

Apache::RedirectLogFix now uses $r->last
[David D. Kilzer <[EMAIL PROTECTED]>]

tweaks for sfio
[Lupe Christoph <[EMAIL PROTECTED]>]

update Apache::SIG docs, thanks to Bill Moseley for the spot

fix get_set_PVp in mod_perl_xs.h
[Michal Jaegermann <[EMAIL PROTECTED]>]

tweaks to compile/run with 5.5.670 + -Dusethreads

$r->hostname now documented [Eric Cholet <[EMAIL PROTECTED]>]

Apache::File methods are now documented 
[Eric Cholet <[EMAIL PROTECTED]>]

avoid quoting  config if args_how == RAW_ARGS
thanks to Michael Schout for the spot

PerlPassEnv maintains its value beyond the first request,
thanks to Chris Thorman for the spot

prevent possible core dump in $r->pnotes if get_module_config returns
NULL, thanks to Kevin Murphy for the spot

fix Apache::Status::status_cv_dump for Perl/5.6-dev

use perl_get_sv("]") instead of patchlevel for $AddPerlVersion

adjust Makefile.PL and Apache::src to parse 1.3.13-dev's httpd.h

Apache::Util functions $r->unescape_uri, $r->unescape_uri_info,
$r->size_string are now documented [Eric Cholet <[EMAIL PROTECTED]>]

$r->request_time is now documented [Jeffrey W. Baker <[EMAIL PROTECTED]>]

Look for the makepl_args.mod_perl file as .makepl_args.mod_perl in
./ and ../ too since the book says it works so. [Ask Bjoern Hansen
<[EMAIL PROTECTED]>]

PerlRestartHandler is now enabled w/ ALL_HOOKS=1 (or EVERYTHING=1)

$r->no_cache(1) will now set the r->headers_out "Pragma" and
"Cache-control" to "no-cache"

`PerlSetEnv PERL5LIB ...' now works again, thanks to Stas for the spot

Apache::test fix for Apache::Table

PerlFreshRestart semantics changed to preserve order of PerlModule's
and not to reload modules while actually iterating over %INC

$r->current_callback now works properly when PerlHandler invokes
subrequests, thanks to James Smith for the spot

if an Apache::Table is NULL return undef (e.g. $r->notes during ChildInit)

ActivePerl compile patches [Jochen Wiedmann <[EMAIL PROTECTED]>]

document that Apache 1.2.x is no longer supported

Apache::src now supported with USE_APXS=1

'make test' AllowOverride None for Directory / 
[Steve Lembark <[EMAIL PROTECTED]>]

disable experimental perlrunxs until future notice

add sanity check for libgdbm

change PL_siggv usage to gv_fetchpv("SIG", ...) for Perl 5.6-tobe
[Andreas J. Koenig <[EMAIL PROTECTED]>]

document $r->get_handlers, $r->set_handlers, $r->push_handlers
[Eric Cholet <[EMAIL PROTECTED]>]

document PerlSetVar [Eric Cholet <[EMAIL PROTECTED]>]

document the fact that $r->dir_config handles keys in a
case insensitive manner [Ken Williams <[EMAIL PROTECTED]>]

avoid logging "rwrite returned -1" multiple times in the
same request [Eric Cholet <[EMAIL PROTECTED]>]

bugfix in write_client() when running under APACHE_SSL
[Michael Douglass <[EMAIL PROTECTED]>]

document the fact that $r->connection->user can be used to set
the authenticated user name [Joshua Gerth <[EMAIL PROTECTED]>]

document the fact that $r->uri sets/gets the UR

Re: mod_perl and Content-Negotiation

[Doug MacEachern]

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: Problems building GTop...

[Doug MacEachern]

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

[Doug MacEachern]

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: Getting PerlSetVar's at PerlModule time...

[Doug MacEachern]

On Thu, 27 Jan 2000, Matt Sergeant wrote:

> Am I just stupid, or can you not get at PerlSetVar's at server startup time?
> 
> I've tried:
> 
> Apache->request->dir_config (segfaults)
> Apache->server->dir_config (segfaults)
> and
> Apache::dir_config (script stops, but httpd continues...)
> Apache::dir_config(undef, 'Var') (segfaults)
> 
> This is on the latest cvs version. Should I drop back to 1.21?

support for this wasn't added until post-1.21:
add per-server PerlSetVar variables, accessed using
Apache->server->dir_config or $r->server->dir_config.
$r->dir_config merges them with per-directory variables.
[Eric Cholet <[EMAIL PROTECTED]>]

I just tried it for the first time, core dump here too, patch below
fixes..

--- Apache.xs   1999/12/30 19:22:48 1.84
+++ Apache.xs   2000/01/28 04:55:13
@@ -1847,6 +1847,7 @@
 server_rec *s;
 
 CODE:
+RETVAL = Nullsv;
 if(r && r->per_dir_config) {  
c = (perl_dir_config *)get_module_config(r->per_dir_config, 
 &perl_module);

Re: Static linking of Sybase::DBlib to mod_perl?

[Doug MacEachern]

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: setting perl handler based on MIME type?

[Doug MacEachern]

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  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: Results of calling perl_shutdown in mp_dso_unload

[Doug MacEachern]

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: numerous segv's, bus errors

[Doug MacEachern]

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  
> #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: self url

[Doug MacEachern]

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 I 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: Apache::AuthCookie takeover?

[Doug MacEachern]

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: CGI.pm and QUERY_STRING fixup

[Doug MacEachern]

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: CGI.pm and QUERY_STRING fixup

[Doug MacEachern]

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: problem

[Doug MacEachern]

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: problem

[Doug MacEachern]

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: Can't exec programs ?

[Doug MacEachern]

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: Performance ?'s regarding Apache::Request

[Doug MacEachern]

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: send_fd and timeout problem

[Doug MacEachern]

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: horrible memory consumption

[Doug MacEachern]

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  67681S <   0.07.5
> 6:57/usr/local/apache/bin/httpd
> 9665 nobody-1-1   35728  34M  62401S <   0.06.9
> 5:57/usr/local/apache/bin/httpd
> 9663 nobody-1-1   35312  34M  64121S <   0.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: Problems w/ CGI under mod_perl

[Doug MacEachern]

> 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: Suggested improvements to RegistryLoader.pm - stuff for virtualhosts

[Doug MacEachern]

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: mod_perl bug (mod_perl 1.21; Apache 1.3.9).

[Doug MacEachern]

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: problems with module at root of web site

[Doug MacEachern]

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: Help

[Doug MacEachern]

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: Memory leak/server crashes

[Doug MacEachern]

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: Perl modules in apache configuration

[Doug MacEachern]

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
 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: Status in httpd access log

[Doug MacEachern]

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: mod_perl and Content-Negotiation

[Doug MacEachern]

On Tue, 28 Dec 1999 [EMAIL PROTECTED] wrote:

> I'm using Apache/1.3.9, mod_perl/1.21, mod_ssl/2.4.9, OpenSSL/0.9.4
> with Content Negotiation enabled (mod_negotiation).
> 
> My idea was to use this feature for mod_perl-scripts,also.
> So I created to scripts for testing:
> - test.pl.en
> - test.pl.de
> 
> The first time I accessed /perl/test.pl I got the output of test.pl.de
> (because my favorite Language is "de" ...)
> I changed the Language to "en" in my Browser and reloaded the
> script. But the output was still from test.pl.de.
> 
> It's clear, because the scripts are cached by URI and it was "/perl/test.pl"
> for both tries.
> 
> I have changed following lines in site/5.00503/lib/ApacheRegistry.pm to 
> cache the scripts by absolute filename:
> 
> 62: # del by [EMAIL PROTECTED]
> 63: #my $script_name = $r->path_info ?
> 64: #substr($uri, 0, length($uri)-length($r->path_info)) :
> 65: # $uri;
> 66: # ins by [EMAIL PROTECTED]
> 67: my $script_name = $filename;
> 
> And it seems to work.
> 
> And here are the questions:
> Is it *nice* what I have made ?
> Do You see any troubles (or impacts) with that change ?
> Why do You take the URI ?

Apache::RegistryNG uses the filename instead of uri.  uri was chosen
because there used to be a limit to the length of Perl package names.  and
regardless, shorter package name based on the uri uses less memory and
provides a faster lookup than the filename.

Re: PerlRun and Exporter() vars

[Doug MacEachern]

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: mod_perl 1.21 -> CGI.pm 2.56 error in phase other than conten t

[Doug MacEachern]

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 B, B and by I itself will be
visible.  Should you need the complete set of variables to be
available sooner, your handler code can do so with the
I 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: PerlFreshRestart and %INC

[Doug MacEachern]

On Thu, 2 Dec 1999, Michael Smith wrote:

> I'm experiencing difficulties when using PerlFreshRestart modules that
> depend on %INC.  In my particular case I'm trying to use persistent
> connections in DBI through Apache-DBI, and Apache/DBI is not in %INC
> when PerlFreshRestart causes DBI to be loaded a second time.

there's a change in the cvs tree that might help:
PerlFreshRestart semantics changed to preserve order of PerlModule's
and not to reload modules while actually iterating over %INC

so if you configure:
PerlModule Apache::DBI DBI

they should both be reloaded in that order.

Re: Results of calling perl_shutdown in mp_dso_unload

[Doug MacEachern]

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: [ID 20000118.004] DynaLoader doesn't dlclose XS code on interpreter

[Doug MacEachern]

> 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: A fix in sight: Apache::ASP: crash when placed in startup.pl

[Doug MacEachern]

On Wed, 19 Jan 2000, Gerald Richter wrote:

> >
> > perl_destruct/perl_free are not called at restart, only during child_exit.
> > it looks like that might need to change to finish the dso puzzle.  I
> > experienced some problems there, but that was a few years ago, looks
> > like it's time to revisit.
> >
> 
> But it is called when Apache unloads the modules during startup. Therefore

not perl_destruct()/perl_free(), they are only called in mod_perl by
perl_shutdown(), during child_exit().

> my Apache on NT starts cleanly without the PERL_STARTUP_DONE_CHECK
> workaround :-) and Embperl works the first time on Unix when it's loaded at
> startup time and mod_perl is dynamicly linked. Really great!

excellent!
 
> Doug, I have the patch (with dlclose replaced with ap_os_dso_unload, as I
> posted some hours ago) here in the CVS working directory, should I commit
> it?

let's hold off for a little bit, I'd like to understand the problem better
and do some testing of my own first.

Re: a possible bug with Apache::Server::ReStarting

[Doug MacEachern]

> The examples are:
> * Start/Restart - when some heavy startup operation should be performed
> (e.g. a heavy XML parsing and preloading like someone posted awhile ago)

I still don't see a complete example.  if you're inside  in
httpd.conf, then you know the server is starting (or restarting), when do
you need to know the difference between starting/restarting?

> * Stopping - I wrote this runaway watchdog and had to make it a standalone
> program which has no idea whether the server is running. I wanted the code
> to be aware of the server status and spawn from the startup file, and kill
> it when the server is stopping... I guess I can provide more cleanup
> scenarios too. 

can't you just use PerlChildExitHandler?  actually, for this case,
Apache::SubProcess could be changed so it can be called at startup, tied
to the server memory pool, then it would be cleaned up for you when the
pool is destroyed during shutdown.

RE: Proxy example in eagle book does not work

[Doug MacEachern]

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 I field to the
browser:

  $r->headers_in->do(sub {
 my($key, $value) = @_;
 $r->print("$key => $value\n");
 1;
  });

For another example of I, 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 I
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: a possible bug with Apache::Server::ReStarting

[Doug MacEachern]

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
 sections you can always do it on your own:


do_something() unless $My::Init++


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: mod_perl bug (mod_perl 1.21; Apache 1.3.9).

[Doug MacEachern]

what happens if you preload Apache::Registry in httpd.conf:

PerlModule Apache::Registry

On Tue, 18 Jan 2000, John Hughes wrote:

> I have a virtual host to handle https.  The URL's on the main host and the
> virtual host can be pretty similar.  Somethimes mod_perl gets confused,
> thinking that it wants a script from the main host when it actualy should
> be getting one for the virtual host.
> 
> What's going wrong is that once $Apache::Registry::NameWithVirtualHost is
> set to zero it never gets set back to one.
> 
> Here's a pretty trivial fix.
> 
> -- 
> John Hughes <[EMAIL PROTECTED]>, 
> CalvaEDI SA.Tel: +33-1-4313-3131
> 66 rue du Moulin de la Pointe,  Fax: +33-1-4313-3139
> 75013 PARIS.

Re: Can't find modules with mod_perl install

[Doug MacEachern]

On Mon, 17 Jan 2000, gnielson wrote:

> I am trying to figure out why I can not start up httpd now that I have
> compiled Apache 1.3.6 Unix with mod_perl 1.21 with perl 5.004_01
> under Redhat Linux 5.0, and can not run my startup script, even though I have 
> added directories to my path in my startupscript. 
> 
> Whenever I try to run my startup.pl script, I get the error:
> 
> Can't locate object method "module" via package "Apache" at
> /usr/lib/perl5/site_perl/Apache/DBI.pm line  202.
> BEGIN failed--compilation aborted at startup.pl line 23.
> 
> FYI, line 202 is:  if ($INC{'Apache.pm'} and
> Apache->module('Apache::Status'));

Edmund, maybe for 'perl -c' sake, that should be changed to:

if ($ENV{MODPERL} and Apache->module('Apache::Status'))

Re: Run away processes

[Doug MacEachern]

On Mon, 17 Jan 2000, Bill Moseley wrote:

> The httpd.conf Timeout setting doesn't effect mod_perl, it seems, even if
> the client breaks the connection.
> 
> Is there a recommendation on how to catch & stop run away mod_perl programs
> in a way that's _not_ part of the run away program.  Or is this even
> possible?  Some type of watchdog, just like httpd.conf Timeout?

how is it 'running away' exactly?  any insight with strace or gdb?  as of
1.3.6, scripts should be able to continue on after the connection is
broken and apache i/o functions become noops (they don't bother trying to
write to the socket).  does it help if you add to httpd.conf:

PerlFixupHandler Apache::SIG

?

Re: Proxy example in eagle book does not work

[Doug MacEachern]

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: Apache::Registry should allow script to _only_ set return code

[Doug MacEachern]

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: alarm() in Apache::Registry

[Doug MacEachern]

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: Patch to Apache::RedirectFixLog in mod_perl-1.21

[Doug MacEachern]

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=1059028&list=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=2466537&list=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: File upload bug in libapreq

[Doug MacEachern]

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: Perl modules in apache configuration

[Doug MacEachern]

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  block
> executes with error, if they are uncommented, it does NOT
> executes. Second  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: send_fd and timeout problem

[Doug MacEachern]

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: Can't exec programs ?

[Doug MacEachern]

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.

On Thu, 6 Jan 2000, Pierre-Yves BONNETAIN wrote:

>Hello,
> 
>I have recently upgraded one of my systems to Apache 1.3.9, mod_perl 1.21 and
> perl 5.005 (from a apache 1.3.6, mo_perl 1.19 and perl 5.004 basis).
>In the previous setup, my mod_perl programs were running smoothly (modulo my
> own bugs, of course). But now, I get this kind of messages :
> 
> [Wed Jan  5 17:46:49 2000] null: Can't exec "pwd": Permission denied at
> /usr/lib/perl5/5.00503/Cwd.pm line 82.
> [Wed Jan  5 17:46:49 2000] null: Can't exec "pwd": Permission denied at
> /usr/lib/perl5/5.00503/Cwd.pm line 82.
> [Wed Jan  5 17:46:49 2000] null: Can't exec "date": Permission denied at
> /usr/lib/perl5/site_perl/5.005/Date/Manip.pm line 3178.
> 
>when some module uses `command` (command = pwd, date, whatever). At first, 
> those messages where almost systematic. Now, sometimes the system goes through 
> the modules without a hitch, othertimes it fails with this kind of message.
>Any hints to what has changed/what I should correct ?
>Tia,
> -- Pierre-Yves Bonnetain
>http://www.rouge-blanc.com
> 

Re: a possible bug with Apache::Server::ReStarting

[Doug MacEachern]

oops.

On Wed, 29 Dec 1999, Stas Bekman wrote:

> Hi,
> 
> While documenting the 'restart twice on start' apache's behavior, I've
> tested $Apache::Server::ReStarting and $Apache::Server::Starting. 
> 
>  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

see modperl-2.0/ToDo:
- $Apache::ServerStarting in 

I don't think the use $Apache::Server{Re}Starting should be promoted, they
will probably go away in 2.0

Re: a possible bug with Apache::Server::ReStarting

[Doug MacEachern]

> Hi,
> 
> While documenting the 'restart twice on start' apache's behavior, I've
> tested $Apache::Server::ReStarting and $Apache::Server::Starting. 
> 
>  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:
> --
> 
> print STDERR " Apache::Server::Starting   is true  \n" if
> $Apache::Server::Starting;
> print STDERR " Apache::Server::Starting   is false \n" unless
> $Apache::Server::Starting;
> print STDERR " Apache::Server::ReStarting is true  \n" if
> $Apache::Server::ReStarting;
> print STDERR " Apache::Server::ReStarting is false \n" unless
> $Apache::Server::ReStarting;
> 
> 
> 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 
>  Apache::Server::Starting   is true  
>  Apache::Server::ReStarting is false 
> 
> and in the error_log:
> 
>  Apache::Server::Starting   is false 
>  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: your mail

[Doug MacEachern]

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: SegFaults caused by Apache::Cookie during ChildExit

[Doug MacEachern]

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: Attempt to free unreferenced scalar during global destruction.

[Doug MacEachern]

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: A fix in sight: Apache::ASP: crash when placed in startup.pl

[Doug MacEachern]

On Sat, 15 Jan 2000, Daniel Jacobowitz wrote:
... 
> Notice that DBI is never dlclose()'d.  But mod_perl is, when apache
> unloads its modules.  The linker is not clever enough to realize that
> DBI depends on symbols in mod_perl.so.  When mod_perl is reloaded at a
> DIFFERENT address, DBI has no reason to be rebound; its symbols are
> already resolved!

wow, *nice* catch!!  Daniel, I can't thank you and Alan enough for your
efforts here.  it's such a thorny problem to debug, the closest I came was
trying to prevent the dlclose of modperl's libperl.so, but had no idea why
that bandaid prevented the bleeding.  I hadn't heard of ltrace, what a
spectacular looking tool.
I'd really like to get the workaround in 1.22, even if Apache and/or
DynaLoader is the "right" place, we don't have any control over the
release schedules of either and modperl-1.22 is already long overdue.

perl_destruct/perl_free are not called at restart, only during child_exit.
it looks like that might need to change to finish the dso puzzle.  I
experienced some problems there, but that was a few years ago, looks
like it's time to revisit.

thanks again!!

Re: Core dump on graceful restart.

[Doug MacEachern]

> (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: Problem running LWP under modperl (LONG)

[Doug MacEachern]

> Could it be a problem of shared .so perl?  Is that what you're using, or the
> libperl.a version?

I doubt it (perl -V below).  you might need to following some of the
debugging advice in the guide to see what's going on, or even just set:
$SIG{__DIE__} = \&Carp::confess; the stacktrace might shed some light.

Summary of my perl5 (revision 5.0 version 5 subversion 63) configuration:
  Platform:
osname=linux, osvers=2.2.7, archname=i686-linux
uname='linux mojo 2.2.7 #3 smp thu may 13 13:13:23 pdt 1999 i686 unknown '
config_args='-des -Dprefix=/usr/local/devperl'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useperlio=undef d_sfio=undef
use64bits=undef usemultiplicity=undef
  Compiler:
cc='cc', optimize='-O2', gccversion=egcs-2.91.66 19990314 (egcs-1.1.2 release)
cppflags='-Dbool=char -DHAS_BOOL -fno-strict-aliasing -I/usr/local/include'
ccflags ='-Dbool=char -DHAS_BOOL -fno-strict-aliasing -I/usr/local/include'
stdchar='char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt
libc=, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'


Characteristics of this binary (from libperl): 
  Compile-time options:
  Built under linux
  Compiled at Dec  9 1999 14:49:52
  @INC:
/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
.

Re: Problem running LWP under modperl (LONG)

[Doug MacEachern]

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: KeepAlive and mod_perl

[Doug MacEachern]

On Sat, 18 Dec 1999, Stas Bekman wrote:
> 
> >From what I see, mod_perl overrides the whatever settings you have in your
> config file and sets the KeepAlive to Off.

mod_perl doesn't touch the keepalive settings.

Re: [Re: [Re: again - more then one PerlTransHandler]]

[Doug MacEachern]

> 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: Another install question: CGI.pm not found

[Doug MacEachern]

> 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: PerlModule/Require didn't work ??

[Doug MacEachern]

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

[Doug MacEachern]

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: Problems with dynamically-loaded perl modules under Solaris2.5.1

[Doug MacEachern]

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: broken USE_APXS (was Re: Apache::Scoreboard - problem compiling)

[Doug MacEachern]

> Anyone using USE_APXS has any ideas of why USE_APXS makes the installation
> incomplete? 

fixed now in cvs.

Re: Read query string on POST request?

[Doug MacEachern]

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: Hanging processes SOLVED!

[Doug MacEachern]

On Thu, 16 Dec 1999, Tony Demark wrote:

> 
> That got it. I cannot thank you enough. The sites are smokin' now.

great news!
 
> Cause (Please correct me if this is not correct):
> 
>   * AUTOLOADing of Apache::Constants::OPT_EXECCGI() can cause this
> to occur 

seems to be the case.
 
> * Check the CVS tree for fixes and reports - who know, you might
> actually find the answer

true, but in this case it was just coincidence.  the original report was
just DProf output, not the cpu chomping monster that bit you.  I'll add
this incident to my list of reasons I don't like AUTOLOAD :-/

Re: [PATCH] Compiling mod_perl with ActivePerl

[Doug MacEachern]

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: Hanging processes [LONG with debugging output]

[Doug MacEachern]

> (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: troubleshooting seg fault/child exit

[Doug MacEachern]

> What I find odd is that all of the sudden people seem to be coming out of 
> the woodwork about this stuff.  Whe I searched through mailing list 
> archives, some of them going back years, I found something odd...  Many 
> people were talking about this same problem between December of last year 
> and January of this year.  No one found a satisfactory solution (at least, I 
> didn't see one).  Some blamed it on pre-loading CGI.pm in startup.perl, 
> while others blamed it on having a PerlFreshRestart On in the Apache 
> confguration scripts.  This seems to be a pretty big deal, if so many people 
> are complaining under so many configurations, and apparently it has gone on 
> for over a year.

core dumps can happen for many different reasons.  why there are so many
these past couple of days, I don't know, but doubt they are all triggered
by the same thing.  if you could follow suit and post a stacktrace from
gdb, that would help.

Re: apache segfaults on mod_perl dlclose

[Doug MacEachern]

On Tue, 14 Dec 1999, Saar Picker wrote:

> 
> Hrm. Does perl use 0x as a marker? 

yes, see malloc.c

> I thought once an sv was freed it gets a null value or something. 

sure, but with Perls before 5.005_60-ish, Perl's malloc overrides system
malloc/free *everywhere*, not just for Perl data, but also for other C
code using malloc/free in the same runtime

> In any case, this shouldn't be happening due to any strictly perl 
> modules I'm loading. 

true, but pure Perl can't be ruled out as triggering such a bug.

it might help if you can run your server under gdb and post a stacktrace
after this core dump.

Re: Core dump on graceful restart.

[Doug MacEachern]

On Tue, 14 Dec 1999, C. R. Oldham wrote:

> Greetings,
> 
> My Apache core dumps on graceful restart.  I've noticed that it only
> happens after mod_perl pages are accessed, and it seems to have
> something to do with Mysql access as well.  A backtrace from gdb
> indicated the problem was in do_obj_cleanup (maybe a spelling error
> there--I had the core file but it disappeared from my /tmp directory
> after an unexpected reboot).  This is on Debian Linux (Potato) with a
> 2.2.13 kernel.

if you can reproduce the core dump and run:
% gdb httpd core
(gdb) where

the results of that might help.
do you have PerlFreshRestart On, by chance?

Re: troubleshooting seg fault/child exit

[Doug MacEachern]

> [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.

Re: Hanging processes [LONG with debugging output]

[Doug MacEachern]

> (gdb) longmess
>  at /opt/local/perl/Apache/Constants.pm line 19
> Apache::Constants::AUTOLOAD() called at /opt/local/perl/Apache/Registry

hmm, add this to .gdbinit:
define perl_get_sv
set $sv = perl_get_sv($arg0, 0)
printf "%s\n", $sv ? ((XPV*) ((SV*)$sv)->sv_any)->xpv_pv : "undef"
end

and run:

(gdb) perl_get_sv("Apache::Constants::AUTOLOAD")

what does that print?

Re: Limiting CPU (was Re: embperl pages and braindead sucking robots)

[Doug MacEachern]

> > mod_cgi does no waiting. :)  The only wait appears to be in the cleanup
> 
> yes it does, but after mod_perl cleanups are run.  see free_proc_chain() 
> in alloc.c

oh wait, I just said what you said, nevermind, I skimmed too fast..