httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 21222] - mod_include send_parsed_content core dumps
Date Wed, 30 Jul 2003 14:13:11 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21222>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21222

mod_include send_parsed_content core dumps





------- Additional Comments From trawick@apache.org  2003-07-30 14:13 -------
r->filename is at offset 0xd0, right*?  And in your request_rec, that is

0x004f3980:      0x00000000

so yes, NULL is getting passed to strrchr().

The field you're formatting is at offset 0xc8, which for me is unparsed_uri.
And it looks more like a uri than a filename.

*0xd0 is the offset on my 32-bit non-largefile-support Solaris 8 build.

Grab 

http://www.apache.org/~trawick/offsets.c

and build it like this to verify the offset:

apxs -c -p -o offsets offsets.c

Back to the big picture:

This patch ought to keep add_include_vars from searching r->filename string when
it isn't even set:

--- modules/filters/mod_include.c       30 Jul 2003 10:53:10 -0000      1.2
+++ modules/filters/mod_include.c       30 Jul 2003 14:02:19 -0000
@@ -155,7 +155,7 @@
         apr_table_setn(e, "DOCUMENT_PATH_INFO", r->path_info);
     }
     apr_table_setn(e, "USER_NAME", LAZY_VALUE);
-    if ((t = strrchr(r->filename, '/'))) {
+    if (r->filename && (t = strrchr(r->filename, '/'))) {
         apr_table_setn(e, "DOCUMENT_NAME", ++t);
     }
     else {

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message