Mailing-List: contact dev-help@perl.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3ED3F068.80501@stason.org>
Date: Wed, 28 May 2003 09:10:32 +1000
From: Stas Bekman <stas@stason.org>
Organization: Hope, Humanized
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
MIME-Version: 1.0
To: Geoffrey Young <geoff@modperlcookbook.org>
Cc: dev@perl.apache.org
Subject: Re: modperl_require_module failing silently
References: <3ECE3306.20709@modperlcookbook.org> <3ED18C62.6080802@stason.org>
 <3ED21B25.90108@modperlcookbook.org> <3ED2AFAD.9040905@stason.org>
 <3ED387AE.20605@modperlcookbook.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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