Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
segfaults for me in the test suite. Running the server under gdb indicates the segfault is happening during loading of B::Deparse on this line in the test- $r->add_output_filter("out_filter");
And if you add it at the startup, it happens too. I think it tries to
deparse out_filter as a code string, instead of trying to get the code
reference.
Oops, sorry- I think I made a mistake about the failing line... I think it's really the next one that segfaults:
# test adding anon sub $r->add_output_filter(sub { my $filter = shift;
while ($filter->read(my $buffer, 1024)) { $buffer .= "end"; $filter->print($buffer); }
return Apache::OK; });
mod_perl is trying to deparse the anonymous sub, and it needs
B::Deparse for that. (I'm still trying to grok the necessity/safety
of the deparse.)
Right, that makes more sense. The necessity is explained in modperl_handler.c, and pasted here for your convenience (and comments):
#ifdef USE_ITHREADS
/* XXX: perhaps we can optimize this further. At the moment when
* perl w/ ithreads is used, we always deparse the anon subs
* before storing them and then eval them each time they are
* used. This is because we don't know whether the same perl that
* compiled the anonymous sub is used to run it.
*
* A possible optimization is to cache the CV and use that cached
* value w/ or w/o deparsing at all if:
*
* - the mpm is non-threaded mpm and no +Clone/+Parent is used
* (i.e. no perl pools) (no deparsing is needed at all)
*
* - the interpreter that has supplied the anon cv is the same
* interpreter that is executing that cv (requires storing aTHX
* in the handler's struct) (need to deparse in case the
* interpreter gets switched)
*
* - other cases?
*/
handler->cv = NULL;
handler->name = modperl_coderef2text(aTHX_ p, cv);
MP_TRACE_h(MP_FUNC, "[%s] new deparsed anon handler:\n%s\n",
modperl_pid_tid(p), handler->name);If you have a better idea that than, I'm all ears. I don't like using B::Deparse for production, and it's definitely much slower than compiled CV.
And if you do one, then there is no point debugging this issue, if it can be scratched altogether :)
FWIW, the backtrace I get is identical to the one Joe Orton posted.
Me too (now with Joe's hint).
Lately I been finding it easier to get proper backtraces from the
worker mpm by running the tests under gdb (nicely explained in docs/devel/debug/c.pod) instead of trying to examine the core file.
:)
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
