Colin Wetherbee wrote: > Have any of you used mod_perl with Perl 5.10 yet? Are there any gotchas > to consider?
Apparently so. I have found the cause of my sometimes-it-works sometimes-it-doesnt problem for PerlOutputFilterHandlers. I tracked the problem down to MP_CODE_ATTRS(), called from modperl_mgv.c on line 276: handler->attrs = (U32)MP_CODE_ATTRS(cv); I added some MP_TRACE()'s around this line and found out that MP_CODE_ATTRS(cv) returns some random looking data under 5.10. Looking at mod_perl.h, it says: /* betting on Perl*Handlers not using CvXSUBANY * mod_perl reuses this field for handler attributes */ #define MP_CODE_ATTRS(cv) (CvXSUBANY((CV*)cv).any_i32) This must not be a safe bet under perl 5.10.0. I have no idea what to do as an alternative. I don't know enough perl internals :). Here is what the MP_TRACE()'s before and after he MP_CODE_ATTRS() call looks like under 5.8.8: modperl_mgv_resolve: pre MP_CODE_ATTRS attrs: 0 modperl_mgv_resolve: post MP_CODE_ATTRS attrs: 0 Under 5.10.0 its a much different story: modperl_mgv_resolve: pre MP_CODE_ATTRS attrs: 0 modperl_mgv_resolve: post MP_CODE_ATTRS attrs: 9905fb8 The "sometimes-it-works" "sometimes-it-doesnt" behaviour depends on if the right bits end up getting set in the attrs from the random data coming out of MP_CODE_ATTRS(). Oh well, I'm going back to 5.8.8 for now I guess :). I'll file a bug report as well :). Regards, Michael Schout
