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