[QUESTION] mod_perl skipping phases
I am not subscribed to the list, so please copy me on any replies. We have recently upgraded to the latest 1.3.x apache and mod_perl and our code is flagging a warning that it did not before. I am hoping it is the result of a bug fixed in Apache or mod_perl and that I can change our code to detect and ignore it. It seems that sometimes some phases of a request are skipped and the cleanup handler is called. We have a PerlHeaderParserHandler which gathers all sorts of information and stores it in pnotes, and later handlers use this information. However after the upgrade we occasionally, and it is rare, get a warning from the cleanup handler that the data structure is not present in pnotes, which makes me think that the PerlHeaderParserHandler is not being called. In an attempt to see what was causing this I added a warn $r->as_string into the cleanup handler. The request looked valid enough, but there were two things I noticed. 1. This only ever happens on a POST request 2. The response section was always HTTP/1.1 (null) This make me think that the content handler is not being called either. Our system is setup with a lightweight front end apache which proxies requests to a backend mod_perl server. Does anyone know of a circumstance that this can happen ? Thanks, Graham.
Re: untraceable uninit warnings
Ah, this was a while ago,
I did actually trace the problem down. The handler was returning undef
which was causing these warnings. It was just not taht obvious from the
warning given.
Graham.
On Thu, Jun 14, 2001 at 09:48:42AM -0700, Doug MacEachern wrote:
> On Wed, 7 Mar 2001, Graham Barr wrote:
>
> > Does anyone have any idea what could be causing
> >
> > Use of uninitialized value at PerlHandler subroutine
>`VC::Delivery::Cycle::handler' line 1.
> >
> > to appear in the errorlog ?
> >
> > I even added
> >
> > local $SIG{__WARN__} = sub { warn "here" };
> >
> > as the first line of VC::Delivery::Cycle::handler, but it never gets
> > triggered, so it would seem the uninit is before the sub is called.
> >
> > The strange thing is that it is only this one handler that causes
> > such a warning, all others are fine.
>
> this will only happen if you gave Makefile.PL PERL_MARK_WHERE=1
> which will modify CopFILEGV(curcop) if Perl doesn't know what it is for
> some reason. not sure why the WARN hook is being ignored, if you can
> whittle it down to a small test case i will have a look.
>
untraceable uninit warnings
Does anyone have any idea what could be causing
Use of uninitialized value at PerlHandler subroutine `VC::Delivery::Cycle::handler'
line 1.
to appear in the errorlog ?
I even added
local $SIG{__WARN__} = sub { warn "here" };
as the first line of VC::Delivery::Cycle::handler, but it never gets
triggered, so it would seem the uninit is before the sub is called.
The strange thing is that it is only this one handler that causes
such a warning, all others are fine.
Thanks,
Graham.
Re: [new module] proposal Apache::DebugHeaders
On Thu, Mar 30, 2000 at 04:07:38PM -0500, Geoffrey Young wrote: > Hey, I'm not trying to redo anyone's work or step on toes... I am sure your not, but on the other hand when two modules are so close in functionality it can help to merge them. There are several reasons why this can be benificial, not least that it cuts down on duplication of effort > > I looked at DumpHeaders and thought that my stuff didn't quite fit in > becuase: > 1) it's longer - DumpHeaders is short and sweet That;'s no reason why it cannot be extended. Like many modules on CPAN DumpHeaders was written to meet a specific task. That does not mean enhancements cannot be added. > 2) it's my attempt at trying to make something OO and extensible And I would encourage everyone to take a learning cycle, it's fun. > 3) it has functionality that DumpHeaders doesn't So extend it. > (and doesn't 'allow' for > by name) Huh? > 4) it allows you to track stuff throughout the request cycle (for modules > that change them) extend > > Here's the code (minus documentation - if it isn't appropriate it isn't. > Let me know what you think - I'm open to anything... It seems to me that these two modules are VERY close in many aspects yet both have something the other does not. The two main things I see in DumpHeaders that are not in yours are the ability to specify a log file (I think yours goes to the standard apache log) and the ability to specify which IP addresses to dump headers for, this is VERY useful when trying to debug a problem on a live site that only a few people see, dumping all headers is just too much. So that said, what would it take to add these two features to yours ? I it could do that, and support the PerlSetVars that DumpHeaders uses then it could just be a drop in replacement. Graham.
