On Monday 30 April 2007 22:22, Philippe M. Chiasson wrote: > And that doesn't seem logical at all. In all cases, since the initial int= > erpreter > is tied up in modperl_response_handler() a new one shouldn't be needed to= > dispatch > that handler part.
I have found similar bug. Try $r->push_handlers(PerlCleanupHandler=>'some_named_function') from a TranslationHandler or so. modperl_interp_unselect calls modperl_config_request_cleanup --> modperl_config_request_cleanup --> modperl_callback_per_dir --> modperl_callback_run_handlers --> modperl_interp_select. modperl_interp_select then selects another interpreter to do the cleanup. Then at the end of modperl_callback_run_handlers modperl_interp_unselect is called for the interpreter that did the cleanup. Now the story repeats eating up all interpreters. When push_handlers is called from a mod_perl response handler the same behavior is seen due to the previous bug, the missing rcfg->interp. However with a perl-script handler something changes. Now the right interp is found in rcfg->interp. But nevertheless it recurses because modperl_callback_run_handlers calls modperl_interp_unselect while modperl_callback_run_handlers was actually called from modperl_interp_unselect. In the end I got a segfault. So, I think either modperl_interp_unselect or modperl_config_request_cleanup needs a flag that says "do not recurse". Maybe interp->flags is a good place for a flag that says "in unselect" or so. Or maybe a cleaner way is to use interp->refcnt. Simply increment it each time modperl_interp_select returns it. For what I can see refcnt isn't used at all by now. Yes, on a second thought that is what I'd prefer. Thoughts? Torsten
pgpDDMcVB00QV.pgp
Description: PGP signature
