httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [SUBMIT] mod_gzip 2.0.26a ( Non-debug version )
Date Mon, 17 Sep 2001 01:38:47 GMT


> > 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 ).

>  > 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.


View raw message