Re: threaded server + scope=handler + PerlCleanupHandler: another similar bug

[Torsten Foertsch <to...@gmx.net>]

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