[EMAIL PROTECTED] wrote:
Author: stas
Date: Fri May 20 20:31:05 2005
New Revision: 171191
URL: http://svn.apache.org/viewcvs?rev=171191&view=rev
Log:
for some reason modperl_interp_unselect(interp) breaks prefork
Modified:
perl/modperl/trunk/src/modules/perl/modperl_module.c
Modified: perl/modperl/trunk/src/modules/perl/modperl_module.c
URL:
http://svn.apache.org/viewcvs/perl/modperl/trunk/src/modules/perl/modperl_module.c?rev=171191&r1=171190&r2=171191&view=diff
==============================================================================
--- perl/modperl/trunk/src/modules/perl/modperl_module.c (original)
+++ perl/modperl/trunk/src/modules/perl/modperl_module.c Fri May 20 20:31:05
2005
@@ -192,7 +192,8 @@
if (!base_obj || (base_obj == add_obj)) {
#ifdef USE_ITHREADS
- modperl_interp_unselect(interp);
+ /* XXX: breaks prefork
+ modperl_interp_unselect(interp); */
if (orig_perl) {
MP_PERL_CONTEXT_RESTORE;
}
@@ -246,7 +247,8 @@
}
#ifdef USE_ITHREADS
- modperl_interp_unselect(interp);
+ /* XXX: breaks prefork
+ modperl_interp_unselect(interp); */
if (orig_perl) {
MP_PERL_CONTEXT_RESTORE;
}
First of all, anybody has an idea why that modperl_interp_unselect(interp)
call crashes in prefork?
#0 0xb7cd0d24 in pthread_mutex_lock () from /lib/tls/libpthread.so.0
#1 0xb7b6ec46 in modperl_tipool_putback_base (tipool=0x0, listp=0x0,
data=0x82ab0b8,
num_requests=0) at modperl_tipool.c:296
#2 0xb7b6f1b2 in modperl_tipool_putback_data (tipool=0x0, data=0x82ab0b8,
num_requests=0) at modperl_tipool.c:392
#3 0xb7b6d8c9 in modperl_interp_unselect (data=0x82ab0b8) at
modperl_interp.c:295
#4 0xb7b8340c in modperl_module_config_merge (p=0x8137758, basev=0x93ccec0,
addv=0x93c84c0, type=2) at modperl_module.c:195
#5 0xb7b83a45 in modperl_module_config_srv_merge (p=0x8137758,
basev=0x93ccec0,
addv=0x93c84c0) at modperl_module.c:264
Now it looks like that select/unselect is a waste of time, since most of
the time we already have a valid global context. Since we need to
store/restore the original anyway, why not just use it if it's available?
The whole context juggling story needs to be reviewed all over the code.
I'm sure we get random segfaults in thread tests due some code not
resetting the context right. In this case it was easy to figure out the
guilty code as it was obvious that moving the custom directive outside of
the container was "fixing" the segfault, so it clearly pointed to the
merging function.
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
