[EMAIL PROTECTED] wrote:
Hi

Perl Version: Any version after 5.005  (Tested on 5.8.0)
mod_perl Version: 1.27
Apache Version: 1.3.27

With the assistance of IBM we may have highlighted a possible bug within mod_perl/perl.

The problem started as we could not load the IBM Websphere 5 Apache plugin if mod_perl 
was enabled. (On Solaris or Reh-Hat Linux)  We narrowed this down to any mod_perl 
built against perl after 5.005.  IBM support assisted us and we managed to enable a 
truss report that clearly shows the following.

-----------------------------------------------------
Apache server calls WAS plug-in as_init() function twice. In as_init(), plug-in first checks if a WAS environment variable has been set. In order to avoid being initialized twice, when as_init() is first called, plug-in sets the environment variable, and skips the rest
initialization. When as_init() is called again, WAS plug-in will be initialized.

Unrelated to the bug report, how does it deal with restart? It'll run as_init() with full initialization again, since env var will be set. Why not doing the init on the very first start, if you really want to call it once.


In this customer's case, the WAS environment set by WAS plug-in was wiped out by mod_perl. Therefore, when as_init() was called for the second time, plug-in initialization was skipped again. Since plug-in was not initialized correctly, pthread mutex was not created, plug-in log was not opened, and later crash happened when request was passed to
plug-in. If mod_perl had not incorrectly freed the storage that WAS plug-in used for an environment variable, WAS plug-in initialization would have completed successfully and the crash on first request would not have occurred. Following are related information from truss output: -> ap_init_modules(0x7f4a0, 0x7f4c8, 0x7c64c, 0xff23c004) -> mod_app_server_http_eapi_new:as_init(0x7f4c8, 0x7f4a0, 0xfe02c9e0,
0x0)




-> libc:getenv(0xfe072e6c, 0x0, 0x0, 0x0) <- libc:getenv() = 0 -> libc:putenv(0xd26a0, 0xd26a0, 0x0, 0xc6ebc)
-> libc:malloc(0x94, 0xff23f0e8, 0x0, 0xc6e30)
-> libthread:mutex_lock(0xff240600, 0x7a398, 0x0, 0xff23c004)
<- libthread:mutex_lock() = 0
-> libc:_malloc_unlocked(0x94, 0x0, 0x0, 0xff23c004)
-> libc:cleanfree(0x0, 0xff242844, 0x0, 0xff2427c0)
<- libc:cleanfree() = 0
-> libc:t_delete(0xcf7c0, 0x0, 0xff2427c4, 0xff242844)
-> libc:t_splay(0xcf7c0, 0x798c8, 0x0, 0x0)
<- libc:t_splay() = 0
<- libc:t_delete() = 0xcf7c0
<- libc:_malloc_unlocked() = 0xcf7c8
-> libthread:mutex_unlock(0xff240600, 0xcf7c0, 0xff23c004, 0x98)
<- libthread:mutex_unlock() = 0
<- libc:malloc() = 0xcf7c8 -> libc_psr:memcpy(0xcf7c8, 0xc6e30, 0x94, 0xc6e30) <- libc_psr:memcpy() = 0xcf7c8 <- libc:putenv() = 0 <- mod_app_server_http_eapi_new:as_init() = 0x7f4c8 -> libperl:perl_module_init(0x7f4c8, 0x7f4a0, 0xfe1730c0, 0x0) ... ... -> libperl:Perl_safesysfree(0xcf7c8, 0xcf7c8, 0x95600, 0x95600) <- libperl:Perl_safesysfree() = 0xcf7c8 ... ... <- libperl:perl_module_init() = 0x7f4c8 ... ... <- ap_init_modules() = 0x7f4a0

Confusingly mod_perl 1's shared lib has the same name as perl's shared lib libperl.so. So libperl:Perl_safesysfree() is not a mod_perl call but a perl's one. mod_perl.c has this code:


    /* 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);

my_setenv is Perl_my_setenv which you can find in util.c in the perl source. It performs a full copy of the environ data the first time it's used unless it thinks that it's safe to use putenv. So may be the problem is coming from there.

BTW, I don't remember such a problem being ever reported. I could be wrong though.

--
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

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



Reply via email to