Hi,
As a follow-up to my previous post, I have found that the mod_perl Apache
configuration option "PerlOptions -Enable" is what causes the problems
described below. Any virtual hosts with this option don't get initialized
with an interpreter. My original solution is only partial. It gets past the
Apache start-up phase but any requests to a virtual host with "PerlOptions
-Enable" cause a segmentation fault during the request clean-up phase (the
request does get serviced and correct results are returned to the web browser).
Here is a backtrace from a representative core dump during request clean-up
in a virtual host with a non-enabled Perl interpreter:
#0 0x00007f5696c68a12 in modperl_interp_get (s=0x1a42f30) at
modperl_interp.c:147
#1 0x00007f5696c69154 in modperl_interp_select (r=0x409c930, c=0x40856d8,
s=0x1a42f30) at modperl_interp.c:440
#2 0x00007f5696c6af65 in modperl_config_req_cleanup (data=0x409c930) at
modperl_config.c:366
#3 0x00007f5697f1100e in run_cleanups (cref=<optimized out>) at
memory/unix/apr_pools.c:2352
#4 apr_pool_destroy (pool=0x40a7288) at memory/unix/apr_pools.c:814
#5 0x00007f5697f10fe5 in apr_pool_destroy (pool=0x409c8b8) at
memory/unix/apr_pools.c:811
#6 0x00000000004583a6 in remove_empty_buckets (bb=bb@entry=0x4085bb0) at
core_filters.c:721
#7 0x00000000004586e5 in send_brigade_nonblocking (s=0x4085440,
bb=bb@entry=0x4085bb0, bytes_written=bytes_written@entry=0x4085b68,
c=c@entry=0x40856d8) at core_filters.c:711
#8 0x0000000000459638 in ap_core_output_filter (f=0x4085a98, new_bb=0x0) at
core_filters.c:468
#9 0x00000000004c0457 in process_socket (my_thread_num=2, my_child_num=1,
cs=0x4085648, sock=0x4085440, p=0x40853b8, thd=0x1b42de8) at event.c:1120
#10 worker_thread (thd=0x1b42de8, dummy=<optimized out>) at event.c:1960
#11 0x00007f5697699b50 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#12 0x00007f56971df95d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#13 0x0000000000000000 in ?? ()
My short-term fix has been to remove any "PerlOptions -Enable" directives
from my Apache configuration files. A longer term solution should probably
not hook into any requests to virtual hosts where mod_perl is not enabled.
Best,
Geoff Mottram
On 12/26/2015 12:52 AM, Geoff Mottram wrote:
Hi,
I have found an Apache-2.4.18 configuration that causes mod_perl-2.09 to
crash when using ITHREADS. Since my configuration file is complicated, I
thought it would be easier to explain the conditions in the mod_perl source
code that cause the problem to occur.
In mod_perl.c around line 388, there is the following code:
/* the base server could have mod_perl callbacks disabled, but it
* still needs perl to drive the vhosts */
if (!MpSrvENABLE(scfg) && s->is_virtual) {
MP_TRACE_i(MP_FUNC, "mod_perl disabled for server %s", vhost);
scfg->mip = NULL;
return OK;
}
In other words, there are certain Apache virtual host configurations that
cause some scfg structures to operate without a mip pointer. This causes
segmentation faults in at least two places in mod_perl that do not check if
"scfg->mip" is NULL before using mip as a pointer. The first place is in
mod_perl.c at line 512:
if (scfg->mip->tipool->idle) {
My solution was to wrap the entire if/else statement with the following lines:
if (scfg->mip) {
...
}
The other place this is a problem is in modperl_interp.c at line 504:
PerlInterpreter *perl = scfg->mip->parent->perl;
The same solution seems to work as well:
if (scfg->mip) {
...
}
Thanks for all of your good work on mod_perl.
Best,
Geoff Mottram
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org
