perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Mottram <>
Subject Re: Non mod_perl virtual hosts cause mod_perl-2.0.9 to crash
Date Sat, 26 Dec 2015 18:17:43 GMT

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 
#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 
#3  0x00007f5697f1100e in run_cleanups (cref=<optimized out>) at 
#4  apr_pool_destroy (pool=0x40a7288) at memory/unix/apr_pools.c:814
#5  0x00007f5697f10fe5 in apr_pool_destroy (pool=0x409c8b8) at 
#6  0x00000000004583a6 in remove_empty_buckets (bb=bb@entry=0x4085bb0) at 
#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 
#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 
#12 0x00007f56971df95d in clone () from /lib/x86_64-linux-gnu/
#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.


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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message