perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Olsen <jame...@planetolsen.com>
Subject Would like mod_perl 1.29 to include more information on fatal errors
Date Thu, 03 Sep 2009 15:32:22 GMT
Hello,

We are running Apache/1.3.37 with mod_perl/1.29. We use the regular 
mod_perl API to install custom access, authentication, authorization, 
fixup, content, and logging handlers. 

Once in a great while we run into random "Undefined subroutine
XX::Clients::YY::ContentHandler::handler called.\n" messages, where XX
represents our internal namespace for our packages and YY a specific 
client.

A snippet of typical Apache configuration is something like this for a 
virtual host:

 PerlAuthenHandler       XX::Account::AuthenHandler
 PerlAuthzHandler        XX::Account::AuthzHandler
 <Files blah>
   SetHandler  perl-script
   PerlHandler XX::Clients::YY::ContentHandler
 </Files>

When we get the undefined subroutine message, it looks like this:

[Wed Sep  2 08:43:30 2009] [error] Undefined subroutine &XX::Clients::YY::ContentHandler::handler
called.\n

The user sees a "white page" when this happens. No error message... but 
no content either. Usually hitting refresh will bring up the page 
they wanted, but it's obviously bad to have users experience "random"
empty/white pages.

The literal backslash and literal n are both (literally) in the logged
message in the error log, which is why I think this error is coming
from Perl and is just getting passed through by mod_perl to Apache;
nothing is interpreting the line and translating the two characters 
"\" and "n" into a newline.

Usually we can track this down in our QA and production environments
to a module that relies on a different module that we failed to "use."
It works most of the time because some earlier hit caused the Apache
process to load one of our custom modules that in-turn use'd the
module the later module referenced, so it was in coincidentally in
memory the vast majority of the time it was referenced. The problem is
when a clean/new Apache process served the faulty module *first*,
before serving any other custom content, and then we would get the
"Undefined subroutine" type of message.

However, we've checked everything we can think of and we're unable to
track down the problem in a particular set of custom modules for a
client where this problem keeps happening for a small percentage of
the hits. Sometimes the problem will also happen in our development
environment, but then it is usually due to a compilation error (like
bad syntax) where StatINC tried to load the new version of the module
from disk and it failed to compile. When that happens, there is
nothing in memory for that module so the "handler" function is not
defined. Once the syntax error is fixed the problem goes away (in our 
development environment; this cause of the problem is never in our QA 
or production environments)

We've ran out of ideas on why the main "handler" method--in a module
that mod_perl should be loading directly--would generate this message.
There are no preceeding error messages that we can attribute this
error to. We are hoping if we spat out more information about the
request (URI, params, etc) and the state of the process (pid, modules
loaded, etc) we might be able to see what is going on and fix the
problem.

I would like to know if someone has a patch that will dump out more 
information about the hit, such as the requested URI, any parameters 
that are passed, what perl modules are in memory, the process ID, or 
anything at all that might help.

I'm rusty on my C and I've never dug into mod_perl guts before, so I'm
not sure where to even begin to look at adding the output of
information myself on a fatal error (one that prevents a properly
handled response). From what I can tell, it seems like mod_perl is
taking an error from PERL and passing it directly to Apache's error
logging mechanism. I'd like to intercept that call and dump out the
extra information as well as the original error.

Any guidance on patching/hacking mod_perl 1.29 to have more verbose 
error messages would be greatly appreciated.

-- 
James
Funny quotes: "There are 10 types of people in the world. 
Those who understand binary, and those who don't." -- Unknown
"A computer once beat me at chess, but it was no match for me at
kick boxing." -- Emo Philips


Mime
View raw message