perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: modperl_require_module failing silently
Date Tue, 27 May 2003 23:10:32 GMT
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:


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/ 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     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message