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 Wed, 08 Feb 2012 09:33:52 GMT
I was using bleadperl (commit 3673acb0ce). Trying again with perl 5.12.4 I find that by default
httpd.exe crashes on startup with the "panic: free from wrong pool" error in modperl_svptr_table_delete()
as before -- the my_perl which Safefree() picks up is the wrong one. With my previously posted
patch it crashes with that same error a little later on in modperl_env_table_populate(), exactly
as for my bleadperl.

I think my patch is good, but clearly isn't the whole story. Either another similar bug is
lurking somewhere, or perhaps it's due to problems with the interp pool select code that you've
found, because reverting the troublesome LimitExcept change (rev. 1145161) I find that httpd.exe
starts up normally and runs ok as far as compat/request_body.t but then httpd.exe crashes
with the message "Out of memory!" in the error_log. My patch makes no difference to that.
I didn't see that happen with bleadperl, although it had the other problem that I reported
before of the entire test suite getting re-run endlessly instead.

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:

View raw message