Hi Stas
Sorry, are you saying that you feel the problem is in the Perl code rather than
mod_perl ?
I managed to track the fact that the Perl_safesysfree() is a Perl method, but could
not determine if that was the cause or another symptym of the error we are seeing.
Below are some additional sections of the truss that document where the memory
reference gets used and within which mod_perl functions. (The number are just line
numbers for my reference)
I believe the actual problem is somewhere in the perl_cmd_handler_handlers that
releases the memory, when obviously it is still required. Again I don't know if this
is a mod_perl or perl error.
I have noticed that if all I do is load the libperl.so, but do not include the
PerlRequire to setup the additional libraries (Apache.pm, etc) then both modules will
load ok and we don't see this error. The problem being that mod_perl doesn't then
work ;)
Does this help to narrow this down ???
1181544 -> perl_cmd_require
1181547 -> perl_startup
1211069 -> mod_perl_boot
1211070 -> perl_require_module
1564016 - first reference to 0xcf7c8 (realfree)
1931574 <- perl_require_module
1931575 <- mod_perl_boot
1938625 <- perl_startup
1938628 -> perl_load_startup_script
1938661 -> perl_do_file
2002252 - free called on 0xcf7c8 (Perl_safesysfree)
2002547 <- perl_do_file
2002566 <- perl_load_startup_script
2002593 <- perl_cmd_require
2003968 -> perl_cmd_handler_handlers
2003971 -> perl_cmd_push_handlers
2003972 mp_preload_module
2004005 mp_preload_module
2004061 - last reference to 0xcf7c8 before WAS module uses it
(realfree)
2004193 <-perl_cmd_push_handlers
2004194 <- perl_cmd_handler_handlers
3040977 -> ap_init_modules
3040978 -> as_init
3041160 - malloc_unlocked called in 0xcf7c8 by WAS module
3041169 <- as_init
3041170 -> perl_module_init
3310968 <- perl_module_init
3371314 <- ap_init_modules
3373941 -> mp_dso_unload
3397095 - 0xcf7c8 starts being used again by mod_perl (Perl_safesysfree)
3397485 - 0xcf7c8 appears to be cleared (Perl_safesysfree)
3631510 <- mp_dso_unload
6375068 -> ap_process_request - processes first request and then seg faults
Rgds
Darren
UBS Investment Bank
-----Original Message-----
From: Stas Bekman [mailto:[EMAIL PROTECTED]
Sent: 19 May 2004 20:33
To: Heather, Darren
Cc: [EMAIL PROTECTED]
Subject: Re: FW: Possible Bug: mod_perl version 1 conflict with IBM
Websphere Apache plugin
[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
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
