You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Geoffrey Young <ge...@modperlcookbook.org> on 2003/05/23 16:41:10 UTC
modperl_require_module failing silently
hi again
I'm finding it very difficult to resolve module errors without this patch.
--Geoff
Index: src/modules/perl/modperl_mgv.c
===================================================================
RCS file: /home/cvspublic/modperl-2.0/src/modules/perl/modperl_mgv.c,v
retrieving revision 1.25
diff -u -r1.25 modperl_mgv.c
--- src/modules/perl/modperl_mgv.c 17 Apr 2003 08:04:47 -0000 1.25
+++ src/modules/perl/modperl_mgv.c 23 May 2003 14:29:03 -0000
@@ -264,7 +264,7 @@
MP_TRACE_h(MP_FUNC,
"package %s not defined, attempting to load\n", name);
- if (modperl_require_module(aTHX_ name, FALSE)) {
+ if (modperl_require_module(aTHX_ name, TRUE)) {
MP_TRACE_h(MP_FUNC, "loaded %s package\n", name);
if (!(stash = gv_stashpv(name, FALSE))) {
MP_TRACE_h(MP_FUNC, "%s package still does not exist\n",
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: modperl_require_module failing silently
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>> Currently we have the following usages for modperl_mgv_resolve. Only
>> modperl_handler_resolve is using false since the error is logged by
>> itself.
>
>
> if you by "logged by itself" this
>
> > ap_log_error(APLOG_MARK, APLOG_ERR, 0, s,
> > "failed to resolve handler `%s'",
> > handler->name);
>
> then what I'm after is more than that, specifically the ERRSV from this
> part of modperl_require_module
>
> if (SvTRUE(ERRSV)) {
> if (logfailure) {
> (void)modperl_errsv(aTHX_ HTTP_INTERNAL_SERVER_ERROR,
> NULL, NULL);
> }
> return FALSE;
> }
>
> in other words, $@ - why it failed.
No, the critical line is:
return HTTP_INTERNAL_SERVER_ERROR;
which results in error logging, up the calling tree.
at modperl_callback_run_handlers:192
status = modperl_callback(aTHX_ handlers[i], p, r, s, av_args);
MP_TRACE_h(MP_FUNC, "%s returned %d\n", handlers[i]->name, status);
if ((status != OK) && (status != DECLINED)) {
status = modperl_errsv(aTHX_ status, r, s);
in other words, grep for modperl_errsv.
>> However it does logs the failure reason, when resolved at run time.
>> e.g. break t/response/TestModperl/env.pm and run t/TEST -v run
>>
>> What you are not telling me is what kid of callback you are having a
>> problem with. modperl_callback returns the status, which eventually
>> should propogate to Apache.
>
>
> it's not that I'm having difficulty figuring out where the error is in
> the cycle - the callback is a normal handler and I'm doing normal things
> with it. the issue is that you can't perl -cw mod_perl stuff, so I end
> up staring at the code for a very long time trying to find the missing
> semicolon or whatnot. so, I guess the subject is a bit misleading - the
> silence was supposed to mean the lack of $@, not that things just aren't
> working :)
>
> at any rate, if nobody else is having this issue, then I'm not going to
> worry about it since I'm issuing callbacks directly. however, as
> pointed out below, I think it may be a larger issue for people who
> resolve handlers at runtime, in which case we probably need to fix it.
> sorry I don't have the tuits right now to delve into all the scenarios
> properly.
I believe what you have to do is what I've pasted just above. Get the return
code and run modperl_errsv if the status is not OK/DECLINED. Does this work
for you?
>> Can you trace where the error is lost? It should work from XS code, no
>> need to use PerlModule. If it doesn't we need to fix it (without
>> breaking other code ;)
>>
>> This is the usage of modperl_mgv_resolve:
>>
>
>>
>> modperl_handler_perl_get_handlers :
>> ---------------------
>>
>> if (!modperl_mgv_resolve(aTHX_ handler, p, handler->name,
>> TRUE)) {
>> MP_TRACE_h(MP_FUNC, "failed to resolve handler %s\n",
>> handler->name);
>> }
>>
>> modperl_mgv.c:411:
>>
>> modperl_hash_handlers
>> ---------------------
>>
>> modperl_mgv_resolve(aTHX_ handler, p, handler->name, TRUE)
>
>
> these two are the only places that will log $@, and they only happen at
> config time, not runtime, right? this means that if I
>
> $r->push_handlers(PerlFooHandler => "My::Module")
>
> or something similar and My::Module hasn't been seen before, any
> compile-time failures won't be logged.
>
> at least this is how I'm reading what is going on.
I'll add a test for that and if that's the case, will be fixed.
Thanks Geoff.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: modperl_require_module failing silently
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Currently we have the following usages for modperl_mgv_resolve. Only
> modperl_handler_resolve is using false since the error is logged by itself.
if you by "logged by itself" this
> ap_log_error(APLOG_MARK, APLOG_ERR, 0, s,
> "failed to resolve handler `%s'",
> handler->name);
then what I'm after is more than that, specifically the ERRSV from this part
of modperl_require_module
if (SvTRUE(ERRSV)) {
if (logfailure) {
(void)modperl_errsv(aTHX_ HTTP_INTERNAL_SERVER_ERROR,
NULL, NULL);
}
return FALSE;
}
in other words, $@ - why it failed.
> However it does logs the failure reason, when resolved at run time. e.g.
> break t/response/TestModperl/env.pm and run t/TEST -v run
>
> What you are not telling me is what kid of callback you are having a
> problem with. modperl_callback returns the status, which eventually
> should propogate to Apache.
it's not that I'm having difficulty figuring out where the error is in the
cycle - the callback is a normal handler and I'm doing normal things with
it. the issue is that you can't perl -cw mod_perl stuff, so I end up
staring at the code for a very long time trying to find the missing
semicolon or whatnot. so, I guess the subject is a bit misleading - the
silence was supposed to mean the lack of $@, not that things just aren't
working :)
at any rate, if nobody else is having this issue, then I'm not going to
worry about it since I'm issuing callbacks directly. however, as pointed
out below, I think it may be a larger issue for people who resolve handlers
at runtime, in which case we probably need to fix it. sorry I don't have
the tuits right now to delve into all the scenarios properly.
> Can you trace where the error is lost? It
> should work from XS code, no need to use PerlModule. If it doesn't we
> need to fix it (without breaking other code ;)
>
> This is the usage of modperl_mgv_resolve:
>
>
> modperl_handler_perl_get_handlers :
> ---------------------
>
> if (!modperl_mgv_resolve(aTHX_ handler, p, handler->name,
> TRUE)) {
> MP_TRACE_h(MP_FUNC, "failed to resolve handler %s\n",
> handler->name);
> }
>
> modperl_mgv.c:411:
>
> modperl_hash_handlers
> ---------------------
>
> modperl_mgv_resolve(aTHX_ handler, p, handler->name, TRUE)
these two are the only places that will log $@, and they only happen at
config time, not runtime, right? this means that if I
$r->push_handlers(PerlFooHandler => "My::Module")
or something similar and My::Module hasn't been seen before, any
compile-time failures won't be logged.
at least this is how I'm reading what is going on.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: modperl_require_module failing silently
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>
> Stas Bekman wrote:
>
>> Geoffrey Young wrote:
>>
>>> hi again
>>>
>>> I'm finding it very difficult to resolve module errors without this
>>> patch.
>>
>>
>>
>> Can't do that "fix", because modperl_handler_resolve calls
>> modperl_mgv_resolve and handles errors by itself, sending it as a part
>> of the error, which on the way logs the error. Your patch will cause
>> the error to be logged twice.
>
>
> hmm...
>
> btw, why does modperl_mgv_resolve accept logfailure as an argument and
> then ignore it when calling modperl_resolve_module?
true, its use was lost when I've trimmed the magic code to DWIM, that didn't
always work. I've replaced hardcoded FALSE to require with this flag. See if
it helps. patch at the bottom.
>> Can you show a simple case where you have this problem with? is it
>> because modperl_handler_resolve is called before server has been started?
>
>
> well, I'm calling modperl_callback directly from XS, specifying a module
> that hasn't been loaded with PerlModule. when the module has an error,
> all I see it the "failed to resolve handler `%s'" line and not $@, which
> was frustrating. from the looks of it, this may happen any time a
> module is loaded without first using PerlModule, since the only time
> that flag is TRUE is when mod_perl is walking the config, right?
>
> anyway, I guess the solution is to use PerlModule, and perhaps fix
> modperl_mgv_resolve to use that passed flag instead of hardcoding the
> value.
>
> --Geoff
Currently we have the following usages for modperl_mgv_resolve. Only
modperl_handler_resolve is using false since the error is logged by itself.
However it does logs the failure reason, when resolved at run time. e.g. break
t/response/TestModperl/env.pm and run t/TEST -v run
What you are not telling me is what kid of callback you are having a problem
with. modperl_callback returns the status, which eventually should propogate
to Apache. Can you trace where the error is lost? It should work from XS code,
no need to use PerlModule. If it doesn't we need to fix it (without breaking
other code ;)
This is the usage of modperl_mgv_resolve:
modperl_filter.c:1001:
modperl_filter_runtime_add :
---------------------
if (!modperl_mgv_resolve(aTHX_ handler, pool, handler->name, TRUE)) {
Perl_croak(aTHX_ "unable to resolve handler %s\n", handler->name);
}
modperl_handler.c:61:
modperl_handler_resolve :
---------------------
if (!modperl_mgv_resolve(aTHX_ handler, rp, handler->name, FALSE)) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, s,
"failed to resolve handler `%s'",
handler->name);
return HTTP_INTERNAL_SERVER_ERROR;
}
modperl_handler.c:372:
modperl_handler_perl_get_handlers :
---------------------
if (!modperl_mgv_resolve(aTHX_ handler, p, handler->name, TRUE)) {
MP_TRACE_h(MP_FUNC, "failed to resolve handler %s\n",
handler->name);
}
modperl_mgv.c:411:
modperl_hash_handlers
---------------------
modperl_mgv_resolve(aTHX_ handler, p, handler->name, TRUE)
Index: src/modules/perl/modperl_mgv.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_mgv.c,v
retrieving revision 1.25
diff -u -r1.25 modperl_mgv.c
--- src/modules/perl/modperl_mgv.c 17 Apr 2003 08:04:47 -0000 1.25
+++ src/modules/perl/modperl_mgv.c 27 May 2003 00:08:04 -0000
@@ -264,7 +264,7 @@
MP_TRACE_h(MP_FUNC,
"package %s not defined, attempting to load\n", name);
- if (modperl_require_module(aTHX_ name, FALSE)) {
+ if (modperl_require_module(aTHX_ name, logfailure)) {
MP_TRACE_h(MP_FUNC, "loaded %s package\n", name);
if (!(stash = gv_stashpv(name, FALSE))) {
MP_TRACE_h(MP_FUNC, "%s package still does not exist\n",
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: modperl_require_module failing silently
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>> hi again
>>
>> I'm finding it very difficult to resolve module errors without this
>> patch.
>
>
> Can't do that "fix", because modperl_handler_resolve calls
> modperl_mgv_resolve and handles errors by itself, sending it as a part
> of the error, which on the way logs the error. Your patch will cause the
> error to be logged twice.
hmm...
btw, why does modperl_mgv_resolve accept logfailure as an argument and then
ignore it when calling modperl_resolve_module?
>
> Can you show a simple case where you have this problem with? is it
> because modperl_handler_resolve is called before server has been started?
well, I'm calling modperl_callback directly from XS, specifying a module
that hasn't been loaded with PerlModule. when the module has an error, all
I see it the "failed to resolve handler `%s'" line and not $@, which was
frustrating. from the looks of it, this may happen any time a module is
loaded without first using PerlModule, since the only time that flag is TRUE
is when mod_perl is walking the config, right?
anyway, I guess the solution is to use PerlModule, and perhaps fix
modperl_mgv_resolve to use that passed flag instead of hardcoding the value.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: modperl_require_module failing silently
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> hi again
>
> I'm finding it very difficult to resolve module errors without this
> patch.
Can't do that "fix", because modperl_handler_resolve calls modperl_mgv_resolve
and handles errors by itself, sending it as a part of the error, which on the
way logs the error. Your patch will cause the error to be logged twice.
Can you show a simple case where you have this problem with? is it because
modperl_handler_resolve is called before server has been started?
> Index: src/modules/perl/modperl_mgv.c
> ===================================================================
> RCS file: /home/cvspublic/modperl-2.0/src/modules/perl/modperl_mgv.c,v
> retrieving revision 1.25
> diff -u -r1.25 modperl_mgv.c
> --- src/modules/perl/modperl_mgv.c 17 Apr 2003 08:04:47 -0000
> 1.25
> +++ src/modules/perl/modperl_mgv.c 23 May 2003 14:29:03 -0000
> @@ -264,7 +264,7 @@
> MP_TRACE_h(MP_FUNC,
> "package %s not defined, attempting to load\n", name);
>
> - if (modperl_require_module(aTHX_ name, FALSE)) {
> + if (modperl_require_module(aTHX_ name, TRUE)) {
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org