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/cmdparms.pm
> ===================================================================
> --- t/response/TestDirective/cmdparms.pm (revision 1145160)
> +++ t/response/TestDirective/cmdparms.pm (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)
{
...
#ifdef USE_ITHREADS
interp = modperl_interp_pool_select(p, s);
MP_PERL_CONTEXT_STORE_OVERRIDE(interp->perl);
#endif
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/libpthread.so.0
#14 0x00007f65a07a363d in ?? () from /lib64/libc.so.6
#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
name=localhost:8529
process_rec=0x67d218:
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
name=localhost:8560
process_rec=0x67d218:
pool=0x67d128, pconf=0x67f138
(gdb)
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.
Thoughts?
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org
