Mailing List Archive: Non mod_perl virtual hosts cause mod

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-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

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-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org