Re: [MP2] Bug ? Recursion in parsing of PerlSection (Subroutine xxx redefined)

On Tue, 2003-05-27 at 00:27, Sreeji K Das wrote:
> I'm trying to port an application to mod_perl2 (from
> mod_perl-1.xx)
> I've installed latest CVS snapshot mod_perl2
> (modperl-2.0_20030526043139.tar.gz), httpd-2.0.45 and
> perl-5.8.0.
> 
> I think there's a recursion while parsing Perl
> sections.
> To Reproduce:
> 
> $ cat /tmp/app.conf
> LoadModule perl_module "/my_path/mod_perl.so"
> PerlSwitches -I/my_path/Apache2
> -I/my_path/arch/Apache2"
> 
> <Perl >
> @Include = "/tmp/test.conf";
> </Perl>
> 
> $ cat /tmp/test.conf
> <Perl >
>     sub test_sub {
>       print "test_sub() called\n";
>     }
> </Perl>
> 
> Now, if I run http -X -f /tmp/test.conf,
> I get a lot of :
> Syntax error at /tmp/test.conf:5 Subroutine test_sub
> redefined at (eval nnn) line 1
> 
> & in the end
> Syntax error on line 8 of /tmp/app.conf:
> Use of uninitialized value in subroutine entry at
> /my_path/Apache2/Apache/PerlSection.pm line 171.
> 
> (line 8 is the last line - I've removed few comments
> in the example.)
> 
> If I remove the line "use warnings FATAL => 'all';"
> from PerlSection.pm, then it recurses forever.
> 
> On tracking, I found this happening:
> modperl_cmd_perldo() calls modperl_callback(), which
> calls modperl_hook_init(). Subsequently modperl_run()
> is called, which inturn calls modperl_cmd_perldo().
> All the processing happens with the same data (ie.
> code in the same perl section).
> 
> Is this a known bug ? This is a code that used to work
> in mod_perl-1.xxx. This happens only when I include a
> file from  a <Perl> section and the included file has
> <Perl> sections. This problem does not occur if I
> simply use apache Include directive.

After reading your greatly detailled report, I read it again twice.
Then only did it hit me ;-( I know exactly what the problem is and
it is indeed a bug.  The <Perl > logic in mp2 had to be completely
re-implemented and should have been 'identical' in behaviour to mp1.

<Perl >@Include = "XXX"</Perl> is most definitely busted if what you
are including contains a <Perl > block.

I do know why this problems happens, but I am not quite yet certain how
to solve this. <Perl > sections in mp2 are different for mp1, as they
also have handlers, like any other phase.

Since all code in the <Perl > blocks will be evaluated in the same
namespace, recursion can happen.

<Perl >
 @include = "Foo.conf";
</Perl>

Becomes 
@Apache::ReadConfig::Include = "foo.conf";

Then Apache::PerlSections is called in with Apache::ReadConfig as the
namespace argument.

This handler will trigger the processing of the include directive.

So, foo.conf:

<Perl >
 1;
</Perl>

Is evaluated in Apache::ReadConfig's namespace, even if it does nothing.

Once again Apache::PerlSections is called in with Apache::ReadConfig as
the namespace

This handler will once again see

@Apache::ReadConfig::include = "foo.conf";

and here starts the recursion.


This is a hairy problem indeed. I realized this partially in the past,
when re-introducing PerlSaveConfig but didn't think of this particular
recursive possibility.

The way I see it, there is only a few ways to proprely fix this.

1. To use one _extra_ namespace to save the config into, if
PerlSaveConfig is specified, and delete or move elements from
Apache::ReadConfig as it is being processed.

2. To use automatically-generated namespaces for each <Perl > sections,
like ModPerl::Registry, like Apache::ReadConfig::blocknnn or something.

I personally prefer solution #2.

Ideas/suggestions ? If not, I'll probably give a shot at implementing #2
sometime this week.

Gozer out. 


> Issue #2 is that for <Perl> sections to be parsed
> properly, I need to add a space before '>'. Is there a
> fix available for this issue ?
> 
> I'll try to debug & get a patch for the first issue.
> But I think it'd be much faster for some1 who already
> knows the code well.
> 
> thx
> Sreeji
> 
> __________________________________________________
> It's Samaritans' Week. Help Samaritans help others. 
> Call 08709 000032 to give or donate online now at 
> http://www.samaritans.org/support/donations.shtm
-- 
-- -----------------------------------------------------------------------------
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/    F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'

signature.asc
Description: This is a digitally signed message part