Stas Bekman wrote:
After enabling 'PerlSwitches -w' a few new "Use of uninitialized variable" warnings have popped up. One of them was due to this child_exit() handler:
sub ModPerl::Test::exit_handler { my($p, $s) = @_;
$s->log->info("Child process pid=$$ is exiting"); }
which didn't return a value. It actually did return a value via the last call to info(), which according to XS should return XSRETURN_EMPTY, which for some reason left some SV on the stack, which was recognized by Devel::Peek as Undef but it wasn't really &PL_sv_undef.
exactly - undef isn't PL_sv_undef for all definitions of undef, which is partially why I didn't want to explicity check against PL_sv_undef, but rather check first the IV slot, then the PV slot, _then_ fallback.
Other than checking why XSRETURN_EMPTY returned a value at all (which is unrelated to mod_perl), it just shows that a handler can return absolutely anything, when there is no explicit status return, so any guessing on our part won't be much of help.
yup.
I think the generated warning is a good solution, but the problem is that it doesn't show where does it happen, since we have left the scope of the callback by the time we retrieve the value off-the stack. Perl_sv_2iv calls:
void
Perl_report_uninit(pTHX)
{
if (PL_op)
Perl_warner(aTHX_ packWARN(WARN_UNINITIALIZED), PL_warn_uninit,
" in ", OP_DESC(PL_op));
else
Perl_warner(aTHX_ packWARN(WARN_UNINITIALIZED), PL_warn_uninit, "", "");
}
and since PL_op is not defined, it just prints a dummy warnings, with no pointers. If could fake PL_op to point to that handler that was just executed, it'll will tell the exact location of the warning. So "all" we have to figure out is how to fake that PL_op thingy...
Another solution would be to rip-off the logic from Perl_sv_2iv (there are 3 places where it calls report_uninit, and provide a custom warning message, but there is quite a lot of logic to duplicate, which is executed anyway.
Finally we could try to temprorary override the PL_warn_uninit format string to provide a custom error message. may be that will be the easiest thing to do.
uh... sure :)
or we could just check for IV (normal circumstances), PV (coerced ints), PL_sv_undef (real calls to Perl_croak), then throw an official error_log message for anything else.
I'm not against putting things in the error_log if it's due to not following the API, and the API requires that handlers exit with a return code that is meaningful to Apache - various definitions of "undef" are not meaningful. so, save the special cases like die and MP::U::exit() where we fix things (trusting that Perl returns the real PL_sv_undef) just throw the error. something like "Perl handler did not return a valid value" or something. I don't see any reason to break that down into the line number - if we can get the name of the routine from the stash (or anon for a coderef) that ought to be sufficient.
when I'm continually bothered by that map_to_storage "filename not defined" error (which is nonsense), I'm less bothered by error messages like these, which would be rare but helpful to the end-user.
but that's just my thought... knock yourself out if you _want_ to mess with the op stuff :)
I'll post later if I come up with some nice solution.
looking forward to it :)
--Geoff
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
