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
