httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [PATCH] fix segfaults related to ap_custom_response()
Date Fri, 17 Aug 2001 18:43:26 GMT
Hi there.  I wrote in earlier this week about bug #6336 and
ap_custom_response (basically, any use of ap_custom_response() seems to
guaruntee a segfault in ap_die() on the next error response).  The
attached patch (againsts 1.3.20) seems to fix the problem.  I had
someone at work shove about 3.5 million requests into it,  and the
server seems stable with the patch applied.

Here is what I did:

* Added a char** response_code_strings field to the end of request_rec

* Modified ap_custom_response() to set r->response_code_strings ...
previously,  it set conf->response_code_strings, using memory from
r->pool.  After the current request was finished,
conf->response_code_strings still pointed to stuff in the now-defunct
r->pool,  and the next time ap_die() tried to use it to find an
ErrorDocument,  it'd segfault.

* Modified ap_response_code_string() to check if the request_rec has a
response_code_string that applies.  If it doesn't,  it then checks the
per-dir config as before.  This, to me anyway,  is the expected
behavior: if I call ap_custom_response(),  I mean to be setting a
custom response for only the current request,  and I expect it to
override the directory configuration.  

If anybody with more apache-hacking experience wants to suggest another
solution,  I'm game to try implementing it.  But as far as I can tell,
without a fix of some sort,  ap_custom_response() is basically


View raw message