You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by da...@ubs.com on 2004/06/22 14:36:48 UTC

Possible Bug: mod_perl version 1 conflict with IBM Websphere Apache plugin

I have been investigating this problem further.

The problem appears to be if any module tries to set an environment variable during the first init run then it will get wiped out by the shutdown of perl.  This then means that the during the second init run the environment variable will not exist and therefore the module could possibly fail if it depended on it being in place.  I have now recreated this with a simple module of my own.

What I believe is happening .......

The "perl_startup" routine appears to use some of the perl routines to make a copy of the environment, and points the exec process at this new environment.  The "perl_startup" routine is run before any of the init routines.

The init routines then run and a module set an environment variable.  This variable is stored in the new copied environment.

After the init processes finish Apache performs the shutdown of the modules to test the restart process.  During this phase mod_perl runs the "mp_dso_unload" routine which will shutdown perl.  My belief is during this shutdown the new environment is dereferenced, and therefore the environment is set back to the original pointer.  What this means is all the environment variables that were set during the first run of the init process are lost.  The upshot of this is during the second init run you start with a fresh environment.

The reason I am now fairly sure this is the case is if you set the environment variable PERL_DESTRUCT_LEVEL to -1 it forces the "mp_dso_unload" routine NOT to unload perl.  This means the new environment is not lost, and both my test module and the IBM module now work as expected.

I believe the problem lies somewhere in the "perl_startup" routine where it makes changes to the environment.
Possible culprits....

    ....
    perl_clear_env();
    mod_perl_pass_env(p, cls);
    ...

    ...
    /* Force the environment to be copied out of its original location
       above argv[].  This fixes a crash caused when a module called putenv()
       before any Perl modified the environment - environ would change to a
       new value, and the check in my_setenv() to duplicate the environment
       would fail, and then setting some environment value which had a previous
       value would cause perl to try to free() something from the original env.
       This crashed free(). */
    my_setenv("MODPERL_ENV_FIXUP", "0");
    my_setenv("MODPERL_ENV_FIXUP", NULL);


Clearly there has been a change in the way perl does some of the environment handling between 5.005 and 5.8+ as both the IBM module and my test module work fine with 5.005.

My questions are now

1/ What real effect on the system am I likely to suffer having the PERL_DESTRUCT_LEVEL set to -1 ??
2/ Does anyone have any background on the "perl_startup" routine with regard to the environment calls, and in particular the part where a forced copy of the environment is made for a previous crash situation ?  It seems this "fix" might  have a side effect of not allowing any other module to set environment variables during the init phase.

Rgds
Darren Heather

Visit our website at http://www.ubs.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html


Re: Possible Bug: mod_perl version 1 conflict with IBM Websphere Apache plugin

Posted by Geoffrey Young <ge...@modperlcookbook.org>.

darren.heather@ubs.com wrote:
> I have been investigating this problem further.
> 
> The problem appears to be if any module tries to set an environment
> variable during the first init run then it will get wiped out by the
> shutdown of perl.  This then means that the during the second init run
> the environment variable will not exist and therefore the module could
> possibly fail if it depended on it being in place.  I have now recreated
> this with a simple module of my own.

[great analysis snipped]

> Clearly there has been a change in the way perl does some of the
> environment handling between 5.005 and 5.8+ as both the IBM module and my
> test module work fine with 5.005.

that's strange, but by no means improbable :)

> 
> My questions are now
> 
> 1/ What real effect on the system am I likely to suffer having the
> PERL_DESTRUCT_LEVEL set to -1 ?? 2/ Does anyone have any background on
> the "perl_startup" routine with regard to the environment calls, and in
> particular the part where a forced copy of the environment is made for a
> previous crash situation ?  It seems this "fix" might  have a side effect
> of not allowing any other module to set environment variables during the
> init phase.

I'm not entirely certain as to the interaction, but I doubt it would hurt
too much - static mod_perl compilations (typically the norm on large sites)
do not destroy the interpreter between restarts, so forcing the interpreter
to stick around in that instance is probably ok.  I am not aware of other
side effects to PERL_DESTRUCT_LEVEL simply because I haven't actually heard
of anyone using it.  you might want to check the archives to see what doug
had to say way back when.

HTH

--Geoff

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html