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 [mailto:torsten.foert...@gmx.net] Sent: 07 February 2012 17:02 To: dev@perl.apache.org 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/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
