Mailing List Archive

Endless loop in perl_sections (was: cvs commit: modperl/src/modules/perl perl_config.c)
Hi,

after upgrading form mod_perl-1.24 to 1.24_01 (it's the same for the current
CVS version) I get an endless loop inside my Perl sections.

A MOD_PERL_TRACE looks like:

"last line of my startup.pl" at /opt/symphony/etc/httpd/startup.pl line 68,
<DATA> chunk 1.
bootstrapping <Perl> sections: arg=/opt/symphony/etc/httpd/startup.pl,
keys=69
loading perl module 'Apache'...ok
loading perl module 'Tie::IxHash'...ok
perl_section: </Files>
perl_section: <Directory /CVS(/|$)>
Deny from all (OK) Limit=no
Order allow,deny (OK) Limit=no
perl_section: <Directory /_vti_(/|$)>
Deny from all (OK) Limit=no
Order allow,deny (OK) Limit=no
perl_section: </Directory>
.PerlSetEnv' directive is TAKE2, (0 elements)
SVt_PV: $SSLSessionCache = dbm:/opt/symphony/log/ssl_scache'
handle_command (SSLSessionCache dbm:/opt/symphony/log/ssl_scache): OK
SVt_PV: $PerlRequire = /opt/symphony/etc/httpd/startup.pl'
handle_command (PerlRequire /opt/symphony/etc/httpd/startup.pl):
PerlRequire: arg=/opt/symphony/etc/httpd/startup.pl'
attempting to require /opt/symphony/etc/httpd/startup.pl'
bootstrapping <Perl> sections: arg=/opt/symphony/etc/httpd/startup.pl,
keys=69
loading perl module 'Apache'...ok
loading perl module 'Tie::IxHash'...ok
perl_section: </Files>
perl_section: <Directory /CVS(/|$)>
....

The first line is a warn that my startup.pl outputs. As you see the
PerlRequire is done again (for the same file) which calls the bootstrapping
<Perl> sections. This continues until the server runs output of memory...

After looking a little bit around, I found that the reason for that
behaviour is the following change. If I revert this change (at least in the
PerlRequire part), everything works as before. Because I am not sure what
was the reason for this change, I cannot suggest a fix, other then reverting
it.

Gerald

----- Original Message -----
From: <dougm@locus.apache.org>
To: <modperl-cvs@apache.org>
Sent: Thursday, September 28, 2000 4:53 AM
Subject: cvs commit: modperl/src/modules/perl perl_config.c


> dougm 00/09/27 20:53:02
>
> Modified: src/modules/perl perl_config.c
> Log:
> fix %Apache::ReadConfig:: processing for PerlRequire'd files
>
> Revision Changes Path
> 1.107 +16 -18 modperl/src/modules/perl/perl_config.c
>
> Index: perl_config.c
> ===================================================================
> RCS file: /home/cvs/modperl/src/modules/perl/perl_config.c,v
> retrieving revision 1.106
> retrieving revision 1.107
> diff -u -r1.106 -r1.107
> --- perl_config.c 2000/09/27 23:51:34 1.106
> +++ perl_config.c 2000/09/28 03:53:01 1.107
> @@ -600,21 +600,20 @@
> dTHRCTX;
> return SvPV(ERRSV,n_a);
> }
> - }
> - else {
> - return NULL;
> +#ifdef PERL_SECTIONS
> + else {
> + if (CAN_SELF_BOOT_SECTIONS) {
> + perl_section_self_boot(parms, dummy, arg);
> + }
> + }
> +#endif
> }
> }
> -
> - if (cls->PerlModule) {
> + else {
> + /* Delay processing it until Perl starts */
> *(char **)push_array(cls->PerlModule) = pstrdup(parms->pool,
arg);
> }
>
> -#ifdef PERL_SECTIONS
> - if(CAN_SELF_BOOT_SECTIONS)
> - perl_section_self_boot(parms, dummy, arg);
> -#endif
> -
> return NULL;
> }
>
> @@ -633,20 +632,19 @@
> dTHRCTX;
> return SvPV(ERRSV,n_a);
> }
> +#ifdef PERL_SECTIONS
> else {
> - return NULL;
> + if (CAN_SELF_BOOT_SECTIONS) {
> + perl_section_self_boot(parms, dummy, arg);
> + }
> }
> +#endif
> }
> }
> -
> - if (cls->PerlRequire) {
> + else {
> + /* Delay processing it until Perl starts */
> *(char **)push_array(cls->PerlRequire) = pstrdup(parms->pool,
arg);
> }
> -
> -#ifdef PERL_SECTIONS
> - if(CAN_SELF_BOOT_SECTIONS)
> - perl_section_self_boot(parms, dummy, arg);
> -#endif
>
> return NULL;
> }
>
>
>



-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
Re: Endless loop in perl_sections (was: cvs commit: modperl/src/modules/perl perl_config.c) [ In reply to ]
On Tue, 12 Dec 2000, Gerald Richter wrote:

> Hi,
>
> after upgrading form mod_perl-1.24 to 1.24_01 (it's the same for the current
> CVS version) I get an endless loop inside my Perl sections.
>
> A MOD_PERL_TRACE looks like:
>
> "last line of my startup.pl" at /opt/symphony/etc/httpd/startup.pl line 68,
> <DATA> chunk 1.
> bootstrapping <Perl> sections: arg=/opt/symphony/etc/httpd/startup.pl,
> keys=69
> loading perl module 'Apache'...ok
> loading perl module 'Tie::IxHash'...ok
> perl_section: </Files>
> perl_section: <Directory /CVS(/|$)>
> Deny from all (OK) Limit=no
> Order allow,deny (OK) Limit=no
> perl_section: <Directory /_vti_(/|$)>
> Deny from all (OK) Limit=no
> Order allow,deny (OK) Limit=no
> perl_section: </Directory>
> .PerlSetEnv' directive is TAKE2, (0 elements)
> SVt_PV: $SSLSessionCache = dbm:/opt/symphony/log/ssl_scache'
> handle_command (SSLSessionCache dbm:/opt/symphony/log/ssl_scache): OK
> SVt_PV: $PerlRequire = /opt/symphony/etc/httpd/startup.pl'
> handle_command (PerlRequire /opt/symphony/etc/httpd/startup.pl):
> PerlRequire: arg=/opt/symphony/etc/httpd/startup.pl'
> attempting to require /opt/symphony/etc/httpd/startup.pl'
> bootstrapping <Perl> sections: arg=/opt/symphony/etc/httpd/startup.pl,
> keys=69
> loading perl module 'Apache'...ok
> loading perl module 'Tie::IxHash'...ok
> perl_section: </Files>
> perl_section: <Directory /CVS(/|$)>
> ....
>
> The first line is a warn that my startup.pl outputs. As you see the
> PerlRequire is done again (for the same file) which calls the bootstrapping
> <Perl> sections. This continues until the server runs output of memory...
>
> After looking a little bit around, I found that the reason for that
> behaviour is the following change. If I revert this change (at least in the
> PerlRequire part), everything works as before. Because I am not sure what
> was the reason for this change, I cannot suggest a fix, other then reverting
> it.

Before this change, the walking of the %ApacheReadConfig:: namespace
populated by a PerlRequire directive was ignored (or delayed).

Because the

SVt_PV: $PerlRequire = /opt/symphony/etc/httpd/startup.pl'

from your trace I suspect that inside your script, you are PerlRequir'ing
it again via an $ApacheReadConfig::PerlRequire.

Can I see the relevant part of your config?

Regards

Salvador Ortiz
Re: Endless loop in perl_sections (was: cvs commit: modperl/src/modules/perl perl_config.c) [ In reply to ]
> Before this change, the walking of the %ApacheReadConfig:: namespace
> populated by a PerlRequire directive was ignored (or delayed).
>
> Because the
>
> SVt_PV: $PerlRequire = /opt/symphony/etc/httpd/startup.pl'
>
> from your trace I suspect that inside your script, you are PerlRequir'ing
> it again via an $ApacheReadConfig::PerlRequire.
>

No, I don't do that!

> Can I see the relevant part of your config?
>

Here is my startup.pl which is loaded via $PerlRequire. The
modules/functions that are called do _nothing_ with the mod_perl config
(i.e. don't touch the ApacheReadConfig namespace). I really don't think it's
a fault on my side, but maybe I am wrong...

Gerald


use Apache::Status ;
use Apache::Session ;

use Apache::DBI ;
$Apache::DBI::DEBUG = 99 ;
use Apache::Session ;

BEGIN
{
eval "use Apache::Session::Win32" ;
eval "use Apache::Session::Embperl" ;
}


use HTML::Embperl ;
use DBIx::Recordset ;

use ecos::DBTool ;
use symphony ;
use symphony::Config ;
use WebDAV::Monitor ;
use symphony::FilesystemInput ;

use Net::Domain ;

my $perlmods ;
my $perlvars ;
my $mod ;
my $var ;
warn 1 ;
my $runcfg = symphony::Config -> new ('run') ;
warn 2 ;
my $editcfg = symphony::Config -> new ('edit') ;
my $cfg = $runcfg?$runcfg:$editcfg ;

warn 3 ;


if ($perlmods = $cfg -> {PerlModules})
{
foreach $mod (@$perlmods)
{
eval "use $mod" ;
die $@ if ($@) ;
}
}

if ($perlvars = $cfg -> {PerlVars})
{
foreach $var (@$perlvars)
{
eval $var ;
die $@ if ($@) ;
}
}

$DBIx::Recordset::Debug=1 ;

# Preload database metadata
my $dbsymphony = $editcfg -> do_dbdef ({'!KeepOpen' => 0}) ;
my $dbprsy = $runcfg -> do_dbdef ({'!KeepOpen' => 0}) ;


# $WebDAV::Monitor::Log::Self = WebDAV::Monitor::Log -> new ;


warn 4 ;

1;
Re: Endless loop in perl_sections (was: cvs commit: modperl/src/modules/perl perl_config.c) [ In reply to ]
On Tue, 12 Dec 2000, Gerald Richter wrote:

> > Before this change, the walking of the %ApacheReadConfig:: namespace
> > populated by a PerlRequire directive was ignored (or delayed).
> >
> > Because the
> >
> > SVt_PV: $PerlRequire = /opt/symphony/etc/httpd/startup.pl'
> >
> > from your trace I suspect that inside your script, you are PerlRequir'ing
> > it again via an $ApacheReadConfig::PerlRequire.
> >
>
> No, I don't do that!
>
> > Can I see the relevant part of your config?
> >
>
> Here is my startup.pl which is loaded via $PerlRequire.

Where is declared that $PerlRequire?

> The
> modules/functions that are called do _nothing_ with the mod_perl config
> (i.e. don't touch the ApacheReadConfig namespace).

Ok, the script seen ok.

> I really don't think it's a fault on my side, but maybe I am wrong...

Before the patch, PerlRequire handling was simply broken (it don't
bootstrap Perl sections), so maybe you were using some kind of "work
arround", I'm really interested in trace this down.

Can you please try this in both perl_cmd_module and perl_cmd_require:

#ifdef PERL_SECTIONS
else {
- if(CAN_SELF_BOOT_SECTIONS)
+ if(CAN_SELF_BOOT_SECTIONS && !perl_sections_self_boot)
perl_section_self_boot(parms, dummy, arg);
}
#endif


Salvador Ortiz
Re: Endless loop in perl_sections (was: cvs commit: modperl/src/modules/perl perl_config.c) [ In reply to ]
>
> Where is declared that $PerlRequire?
>

Inside a Perl section..., so PerlRequire inside the Perl Section triggers
perl_section_self_boot, which calls perl_section, which executes the
PerlRequire inside the Perl section....

I think you see what I mean...

>
> Can you please try this in both perl_cmd_module and perl_cmd_require:
>
> #ifdef PERL_SECTIONS
> else {
> - if(CAN_SELF_BOOT_SECTIONS)
> + if(CAN_SELF_BOOT_SECTIONS && !perl_sections_self_boot)
> perl_section_self_boot(parms, dummy, arg);
> }
> #endif
>

That seems to be right fix that I was searching for today morning, just
didn't see it. With this change it works :-)

Maybe it would be better to insert a

if(perl_sections_self_boot)
return ;

at the top of perl_section_self_boot, but I didn't tried that.

Gerald





-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
Re: Endless loop in perl_sections (was: cvs commit: modperl/src/modules/perl perl_config.c) [ In reply to ]
On Tue, 12 Dec 2000, Gerald Richter wrote:

> >
> > Where is declared that $PerlRequire?
> >
>
> Inside a Perl section..., so PerlRequire inside the Perl Section triggers
> perl_section_self_boot, which calls perl_section, which executes the
> PerlRequire inside the Perl section....
>
> I think you see what I mean...

Yes, that Perl section forms your real startup script and now that the
mod_perl config engine is fully reentrant your $PerlRequire was recursing
into perl_section before the original %ApacheReadConfig was cleaned.


> > Can you please try this in both perl_cmd_module and perl_cmd_require:
> >
> > #ifdef PERL_SECTIONS
> > else {
> > - if(CAN_SELF_BOOT_SECTIONS)
> > + if(CAN_SELF_BOOT_SECTIONS && !perl_sections_self_boot)
> > perl_section_self_boot(parms, dummy, arg);
> > }
> > #endif
> >
>
> That seems to be right fix that I was searching for today morning, just
> didn't see it. With this change it works :-)
>
> Maybe it would be better to insert a
>
> if(perl_sections_self_boot)
> return ;
>
> at the top of perl_section_self_boot, but I didn't tried that.

I think the better is to include it in the macro definition in mod_perl.h:

#ifdef PERL_SECTIONS
# ifndef PERL_SECTIONS_SELF_BOOT
# ifdef WIN32
-# define PERL_SECTIONS_SELF_BOOT getenv("PERL_SECTIONS_SELF_BOOT")
+# define PERL_SECTIONS_SELF_BOOT \
+ (getenv("PERL_SECTIONS_SELF_BOOT")&&!perl_sections_self_boot)
# else
-# define PERL_SECTIONS_SELF_BOOT 1
+# define PERL_SECTIONS_SELF_BOOT !perl_sections_self_boot
# endif
# endif
#endif


And document the fact that only the true directives PerlModule and
PerlRequire can trigger the scan of the %ApacheReadConfig namespace but
not $PerlModule nor $PerlRequire.

Anyway %ApacheReadConfig:: isn't documented in the main docs, and that is
the main reason that many people are using long <Perl>...</Perl> sections
that can be sustituted by a simple and cleaner "PerlRequire foobar".


Regards

Salvador Ortiz
Re: Endless loop in perl_sections (was: cvs commit: modperl/src/modules/perl perl_config.c) [ In reply to ]
On Tue, 12 Dec 2000, Salvador Ortiz Garcia wrote:

> Anyway %ApacheReadConfig:: isn't documented in the main docs, and that is
> the main reason that many people are using long <Perl>...</Perl> sections
> that can be sustituted by a simple and cleaner "PerlRequire foobar".

Just to correct a few points :)

1. It's Apache::ReadConfig, not ApacheReadConfig

2. It's fully documented in the guide:
http://perl.apache.org/guide/config.html#Apache_Configuration_in_Perl

3. It's mentioned in the Apache::PerlSections module.

_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Endless loop in perl_sections (was: cvs commit: modperl/src/modules/perl perl_config.c) [ In reply to ]
On Tue, 12 Dec 2000, Stas Bekman wrote:

> On Tue, 12 Dec 2000, Salvador Ortiz Garcia wrote:
>
> > Anyway %ApacheReadConfig:: isn't documented in the main docs, and that is
> > the main reason that many people are using long <Perl>...</Perl> sections
> > that can be sustituted by a simple and cleaner "PerlRequire foobar".
>
> Just to correct a few points :)

Stas, I'm really appreciate your work in the documentation area, but...

> 1. It's Apache::ReadConfig, not ApacheReadConfig

Sorry, no.

From Changes:

=item 1.07_03 - January 8, 1998
...
go back to internal <Perl> sections package name ApacheReadConfig
...

and from perl_config.c:

...
#define PERL_SECTIONS_PACKAGE "ApacheReadConfig"
...

and

...
nk = perl_eval_pv("scalar(keys %ApacheReadConfig::);",TRUE);
...

> 2. It's fully documented in the guide:
> http://perl.apache.org/guide/config.html#Apache_Configuration_in_Perl

Yes, but with the wrong namespace, not a problem when the user uses only
<Perl>...</Perl> Sections, but useless for PerlRequire (recently fixed)
and PerlModule.

> 3. It's mentioned in the Apache::PerlSections module.

Broken, BTW. (fix at the end)


My point is that the bootstrap feature, IMHO one of the most powerfull of
mod_perl (because many Apache modules can be made self-configurables{sp?})
was, in the begining so buggy and that most users and developers
stay away from it and uses only the <Perl>..</Perl> part.

And my bad English can't help.

Salvador Ortiz
Re: Endless loop in perl_sections (was: cvs commit: modperl/src/modules/perl perl_config.c) [ In reply to ]
guys, ApacheReadConfig is the original name, and still the name used
internally.
Apache::ReadConfig is an alias for ApacheReadConfig (see Apache.pm) and is
documented as the public namespace.

for some reason using Apache::ReadConfig internally caused problems, i
can't recall the details (the switchback was nearly 3 years ago) and never
took the time to debug it. the alias has never caused any problems that i
know of, other than this current confusion ;-)
Re: Endless loop in perl_sections (was: cvs commit: modperl/src/modules/perl perl_config.c) [ In reply to ]
> On Tue, 12 Dec 2000, Stas Bekman wrote:
>
> > On Tue, 12 Dec 2000, Salvador Ortiz Garcia wrote:
> >
> > > Anyway %ApacheReadConfig:: isn't documented in the main docs, and that is
> > > the main reason that many people are using long <Perl>...</Perl> sections
> > > that can be sustituted by a simple and cleaner "PerlRequire foobar".
> >
> > Just to correct a few points :)
>
> Stas, I'm really appreciate your work in the documentation area, but...

If something is broken it should be fixed, so I'm not trying to claim
something that's there, when it's not. But see below:

> > 1. It's Apache::ReadConfig, not ApacheReadConfig
>
> Sorry, no.

sorry, yes :)

> >From Changes:
>
> =item 1.07_03 - January 8, 1998
> ...
> go back to internal <Perl> sections package name ApacheReadConfig
> ...
>
> and from perl_config.c:
>
> ...
> #define PERL_SECTIONS_PACKAGE "ApacheReadConfig"
> ...
>
> and
>
> ...
> nk = perl_eval_pv("scalar(keys %ApacheReadConfig::);",TRUE);
> ...

this is the key

./Apache/Apache.pm: *Apache::ReadConfig:: = \%ApacheReadConfig::;


> > 2. It's fully documented in the guide:
> > http://perl.apache.org/guide/config.html#Apache_Configuration_in_Perl
>
> Yes, but with the wrong namespace, not a problem when the user uses only
> <Perl>...</Perl> Sections, but useless for PerlRequire (recently fixed)
> and PerlModule.

Well, why don't you test it? Last time I've tested it - it worked for me.

> > 3. It's mentioned in the Apache::PerlSections module.
>
> Broken, BTW. (fix at the end)

at the end? where?

> My point is that the bootstrap feature, IMHO one of the most powerfull of
> mod_perl (because many Apache modules can be made self-configurables{sp?})
> was, in the begining so buggy and that most users and developers
> stay away from it and uses only the <Perl>..</Perl> part.
>
> And my bad English can't help.
>
> Salvador Ortiz
>
>
>



_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Endless loop in perl_sections (was: cvs commit: modperl/src/modules/perl perl_config.c) [ In reply to ]
On Wed, 13 Dec 2000, Stas Bekman wrote:

> > On Tue, 12 Dec 2000, Stas Bekman wrote:
>
> > > 1. It's Apache::ReadConfig, not ApacheReadConfig
> >
> > Sorry, no.
>
> sorry, yes :)

<HEAD MODE=IN BROWN BAG>

You are right, it's also Apache::ReadConfig ;-)
I'm thinking its time to change the C code. (and my own perl code)

> at the end? where?
going to /dev/null :)

</HEAD>


Salvador
Re: Endless loop in perl_sections (was: cvs commit: modperl/src/modules/perl perl_config.c) [ In reply to ]
On Tue, 12 Dec 2000, Doug MacEachern wrote:

> guys, ApacheReadConfig is the original name, and still the name used
> internally.
> Apache::ReadConfig is an alias for ApacheReadConfig (see Apache.pm) and is
> documented as the public namespace.

I see.

> for some reason using Apache::ReadConfig internally caused problems, i
> can't recall the details (the switchback was nearly 3 years ago) and never
> took the time to debug it. the alias has never caused any problems that i
> know of, other than this current confusion ;-)

Do you think it is worth try to debug it?


Salvador "Too much internally" Ortiz.
Re: Endless loop in perl_sections (was: cvs commit: modperl/src/modules/perl perl_config.c) [ In reply to ]
On Tue, 12 Dec 2000, Salvador Ortiz Garcia wrote:

> Do you think it is worth try to debug it?

i would be happy to see ApacheReadConfig gone and use Apache::ReadConfig
in both places, if you're up for it.
Re: Endless loop in perl_sections (was: cvs commit: modperl/src/modules/perl perl_config.c) [ In reply to ]
nice catch salvador, applied. thanks!