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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
