perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Hay" <>
Subject RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
Date Tue, 14 Feb 2012 09:58:51 GMT
The patch below fixes the problems with MP_LIBNAME (and cwd) not being set correctly when building
Apache::Reload and Apache::SizeLimit.

The problem was that the file-level $b variable was created only once when ModPerl::MM was
first loaded, but that happened before was written. The patch simply
rewrites $b (instead of writing a lexical $build which was never used!) later on, by which
time has been created.

If the patch looks ok then shall I apply it before RC2 is rolled?

(Needless to say, this doesn't fix the more serious problem of the test suite still failing
when httpd.exe crashes with an out of memory error part-way through...)

Index: lib/ModPerl/
--- lib/ModPerl/   (revision 1240026)
+++ lib/ModPerl/   (working copy)
@@ -128,7 +128,7 @@

-    my $build = build_config();
+    $b = build_config();

     # set top-level WriteMakefile's values if weren't set already

-----Original Message-----
From: Steve Hay [] 
Sent: 08 February 2012 09:34
To: Torsten Förtsch;
Cc: Fred Moyer
Subject: RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1


I also still have the warnings from Makefile.PL that I reported before too, which Fred guessed
are due to MP_LIBNAME not getting set correctly. I haven't had a chance to look further into
that yet, sorry :-(

As before, this is all with httpd 2.2.21, with everything built from source in default configurations
using VC++ 2010.

-----Original Message-----
From: Torsten Förtsch []
Sent: 07 February 2012 17:02
Cc: Fred Moyer; Steve Hay
Subject: Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1

On Tuesday, 31 January 2012 15:32:44 Torsten Förtsch wrote:
> worker: I see the same behavior as Steve. I can also confirm that
> r1145161 is  the first commit that shows this behavior. Blame on me!
> $ svn diff -c1145161
> Index: t/response/TestDirective/
> ===================================================================
> --- t/response/TestDirective/        (revision 1145160)
> +++ t/response/TestDirective/        (revision 1145161)
> @@ -134,6 +134,8 @@
>  TestCmdParms "Location"
> -<LimitExcept GET>
> -    TestCmdParms "Limit"
> -</LimitExcept>
> +<Directory />
> +    <LimitExcept GET>
> +        TestCmdParms "Limit"
> +    </LimitExcept>
> +</Directory>
> looks quite innocent.
> Except without the change the limit is part of the server's base config.
> With  it it will be merged at request time.

I think perhaps I have found the culprit. modperl has 2 ways of assigning a perl interpreter
to the request. One is modperl_interp_select() that can be used if we have either a request_rec*
or a conn_rec* or a server_rec*. The other is modperl_interp_pool_select() which is in my
opinion basically a hack to work around the situation when one of the above is hidden on the
stack somewhere but currently not accessible. To do this modperl_interp_select() ties the
interpreter to a pool by storing it in the pool userdata hash. This pool might be a conn_req
or request_rec pool depending on PerlInterpScope.
Now, when modperl_interp_pool_select() is called it hopes that the pool it is passed already
contains an interpreter. If so, all is fine. Otherwise,
modperl_interp_pool_select() hopes that the server_rec it is also passed (or rather the mip
stored there) matches the current request. Unfortunately, this assumption is false for dir
config merger functions. That's what the XXX comment below is about.

modperl_module.c has this piece of code:

 * XXX: vhosts may have different parent interpreters.
static void *modperl_module_config_merge(apr_pool_t *p,
                                         void *basev, void *addv,
                                         int type) { ...
    interp = modperl_interp_pool_select(p, s);

The first request in t/directive/perlrequire.t is a good test to show the problem. With change
1145161 it fails reliably, without it succeeds.

Now, if I set a breakpoint on modperl_interp_pool_select() it is hit only with change 1145161.
Without it modperl_interp_pool_select() is not reached.
So, without 1145161 the interpreter is assigned by modperl_interp_select() while with it modperl_interp_pool_select()
tries to do it (and picks the wrong interpreter pool).

Breakpoint 1, modperl_interp_pool_select (p=0x7f65840028f8, s=0x686848) at modperl_interp.c:341
341         int is_startup = (p == s->process->pconf);
(gdb) bt
#0  modperl_interp_pool_select (p=0x7f65840028f8, s=0x686848) at modperl_interp.c:341
#1  0x00007f6596ab2241 in modperl_module_config_merge (p=0x7f65840028f8, basev=0x2d2a9d0,
addv=0x2d2c210, type=1) at modperl_module.c:186
#2  0x00007f6596ab2b83 in modperl_module_config_dir_merge (p=0x7f65840028f8, basev=0x2d2a9d0,
addv=0x2d2c210) at modperl_module.c:260
#3  0x000000000043d598 in ap_merge_per_dir_configs (p=0x7f65840028f8, base=0x2de09a0, new_conf=0x7f6584009470)
at config.c:248
#4  0x00000000004387d2 in ap_directory_walk (r=0x7f6584002970) at request.c:1195
#5  0x0000000000433c59 in core_map_to_storage (r=0x7f6584002970) at core.c:3621
#6  0x0000000000437978 in ap_run_map_to_storage (r=0x7f6584002970) at request.c:69
#7  0x0000000000439b38 in ap_process_request_internal (r=0x7f6584002970) at request.c:150
#8  0x000000000044a490 in ap_process_request (r=0x7f6584002970) at http_request.c:280
#9  0x0000000000447478 in ap_process_http_connection (c=0x7f6588003748) at http_core.c:190
#10 0x0000000000443898 in ap_run_process_connection (c=0x7f6588003748) at connection.c:43
#11 0x00000000004505b1 in process_socket (bucket_alloc=<optimized out>, my_thread_num=0,
my_child_num=0, sock=0x7f6588003530, p=<optimized out>) at worker.c:544
#12 worker_thread (thd=0x2daf638, dummy=<optimized out>) at worker.c:894
#13 0x00007f65a0c64f05 in start_thread () from /lib64/
#14 0x00007f65a07a363d in ?? () from /lib64/
#15 0x0000000000000000 in ?? ()

Now, if we look at the server_rec passed to modperl_interp_pool_select() it turns out to be
the default server listening on localhost:8529.

(gdb) dump_server_rec s
   pool=0x67d128, pconf=0x67f138

While r->server is the vhost listening on localhost:8560.

(gdb) up 5
#5  0x0000000000433c59 in core_map_to_storage (r=0x7f6584002970) at core.c:3621
3621        if ((access_status = ap_directory_walk(r))) {
(gdb) dump_server_rec r->server
   pool=0x67d128, pconf=0x67f138

What to do now? I'd suggest to revert change 1145161 and get 2.0.6 out (perhaps with Steve's
latest patch). Steve, do you use perl 5.14? If yes, can you try if you see the "panic: free
from wrong pool" also with 5.12?

After that, we should merge the threading branch. There at the very beginning of a request
the request_rec is stored as pool userdata in the request pool. Thus, modperl_interp_pool_select()
can fetch it from there and then use r->server to get an interpreter from the right pool.

The other way would be to make sure there is an interpreter in the request pool before core_map_to_storage().
I think this would make the current mess even worse.


Torsten Förtsch

Need professional modperl support? Hire me! (

Like fantasy?

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

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

View raw message