[snip]
> > Kevin Kiley wrote...
> >
> > That call to mod_gzip_npp() ( Null Pointer Protection ) that remains
> > in the non-debug code was actually an oversight. I have never actually
> > seen the 'r->uri' pointer cause a segfault inside any standard Apache
> > module user-exit, hook, or filter callback.
>
> Cliff Wooley wrote...
>
> It did up until about two weeks ago, but then that was because r->uri was
> set to a completely bogus value (the string "INTERNALLY GENERATED
> file-relative req" or something like that), rather than just "". =-) I
> don't think r->uri can be actually NULL, though (somebody correct me if
> I'm wrong).
By 'never seen r->uri cause a segfault' I meant that I have never seen
the 'r->uri' pointer itself be a 'NULL' value. I don't believe it's possible
unless you have already suffered a memory overwrite during the
request and then it's just a 'symptom' of some other problem.
Solaris is the only OS I know that will blow when using a NULL
pointer in simple STDLIB calls and only then if 'r->uri' pointer
value itself is ZERO ( Not likely ).
[snip]
> > The reason it's a function is that it used to do a whole lot of
> > other things if/when something showed up as NULL ) that
> > weren't apppriate for a macro ( Used to write a complete separate log
> > file for things that turned up NULL during request hooks and such ).
> >
> > In non-debug mode... it's really all pretty irrelevant.
>
> Okay, that makes sense. Thanks for the explanation.
>
> --Cliff
What actually happened here is that we were helping "JP Morgan
Chase and CO" on Wall Street fire up mod_gzip on one of their
gargantuan Solaris machines ( running Apache, of course ).
They were the ones that needed additional logging in the
mod_gzip_npp() Null Pointer Protection call since mod_gzip
in debug mode was helping them track down problems with
their own back-end CGI that had existed for years. It wasn't
until mod_gzip_npp() call was showing them EXACTLY what
parts of the request/response were showing up NULL instead
of containing real values that they were able to finally nail
down some kind of historic problem with their back-end.
We pulled the additional log output from NPP function when
they started to rock and roll but we just left the mod_gzip_npp()
call as a 'safe stub' for any further Solaris debugging they
might want to do.
That's the long and short of all that.
Non-debug code can give this all a clear miss unless
something other than a known 'safe' pointer test like 'r->uri'
is involved and the binary is meant to run under Solaris.
Yours...
Kevin
