"Stephen" <[EMAIL PROTECTED]> wrote:
> I'm no expert at debugging C, but I dont think that the above looks too
> healthy....
Well, I think I have it figured out, more or less. The root cause of it
seemed to be a rather, um, interesting bit of code in
HTML::Mason::ApacheHandler which makes use of string eval and sprintf to
define the handler() subroutine. The intent was to create a handler()
routine suitable for both mod_perl 1 and 2 (prototype of ($$) vs attribute
of : method). However, for some reason or another, handler() was being
called as a regular sub, with one parameter.
Preloading the module and using the explicit Module->handler method syntax
in httpd.conf seems to have fixed it. (Having said that, it seems to be
working without the additional "->handler" now ... *sighs*. Either I failed
to add method handlers to the config before, or I'm collecting on a karmic
debt. Or both....).
As for the segfaults, I patched my mod_perl source to return undef in that
situation as opposed to segfault, which seems slightly more reasonable
behaviour. Patch below:
--- src/modules/perl/Apache.xs-orig Fri Jun 6 12:31:10 2003
+++ src/modules/perl/Apache.xs Thu Aug 28 12:10:53 2003
@@ -2075,7 +2075,10 @@
SvREFCNT_dec(RETVAL); /* in case above did newSV(0) */
cs = (perl_server_config *)get_module_config(s->module_config,
&perl_module);
- TABLE_GET_SET(cs->vars, FALSE);
+ if(cs) {
+ TABLE_GET_SET(cs->vars, FALSE);
+ }
+ else XSRETURN_UNDEF;
}
else XSRETURN_UNDEF;
}
This has taught me more about XS and the um, interesting capabilities of
string eval than I ever wanted to know, I think. Please excuse me whilst I
take a cold shower or three...
Stephen Veiss
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
