Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 74401 invoked by uid 500); 27 Mar 2002 06:46:48 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 74388 invoked from network); 27 Mar 2002 06:46:48 -0000 Date: Wed, 27 Mar 2002 01:42:36 -0500 (EST) From: Cliff Woolley X-X-Sender: root@deepthought.cs.virginia.edu To: dev@httpd.apache.org Subject: mod_include bug(s)? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I've spent the entire evening chasing some wacky mod_include bugs that surfaced as I was doing final testing on the bucket API patch. At first I assumed they were my fault, but upon further investigation I think the fact that they haven't surfaced until now is a coincidence. There are two problems that I can see -- the if6.shtml and if7.shtml files I committed to httpd-test last week to check for the mod_include 1.3 bug has turned up quasi-related problems in mod_include 2.0 as well. Problem 1: When in an #if or #elif or several other kinds of tags, ap_ssi_get_tag_and_value() is called from within a while(1) loop that continues until that function returns with tag==NULL. But in the case of if6.shtml, ap_ssi_get_tag_and_value() steps right past the end of the buffer and never bothers to check and see how long the thing it's supposed to be processing actually is. The following patch fixes it, but there could be a better way to do it. I'm hoping someone out there who knows this code better will come up with a better way to do it. Index: mod_include.c =================================================================== RCS file: /home/cvs/httpd-2.0/modules/filters/mod_include.c,v retrieving revision 1.205 diff -u -d -r1.205 mod_include.c --- mod_include.c 24 Mar 2002 06:42:14 -0000 1.205 +++ mod_include.c 27 Mar 2002 06:41:55 -0000 @@ -866,6 +866,11 @@ int shift_val = 0; char term = '\0'; + if (ctx->curr_tag_pos - ctx->combined_tag > ctx->tag_length) { + *tag = NULL; + return; + } + *tag_val = NULL; SKIP_TAG_WHITESPACE(c); *tag = c; /* First non-whitespace character (could be NULL). */ Problem 2: In the case of if7.shtml, for some reason, the null-terminating character is placed one character too far forward. So instead of #endif you get #endif\b or some such garbage: Breakpoint 1, handle_if (ctx=0x82111b0, bb=0xbffff498, r=0x8226628, f=0x8220d58, head_ptr=0x820bbd8, inserted_head=0xbffff044) at mod_include.c:2552 2552 { 1: *ctx = {state = PARSED, flags = 11, if_nesting_level = 0, parse_pos = 3, bytes_parsed = 36, status = 0, output_now = 0, output_flush = 0, head_start_bucket = 0x820bbb0, head_start_index = 0, tag_start_bucket = 0x820bbb0, tag_start_index = 5, tail_start_bucket = 0x820bbb0, tail_start_index = 32, combined_tag = 0xbffff04c "if", curr_tag_pos = 0xbffff04f "expr=\"$x = y\"\n", re_string = 0x0, re_result = 0x0} (gdb) p ctx->curr_tag_pos - ctx->combined_tag $3 = 3 (gdb) p ctx->curr_tag_pos+ctx->tag_length $4 = 0xbffff06b "\bks" Note the trailing \b in curr_tag_pos that shouldn't be there. I'm at a bit of a loss on this one. I would think the problem must be in get_combined_directive(), but I could be wrong. Again, more eyes would be appreciated. Thanks, Cliff -------------------------------------------------------------- Cliff Woolley cliffwoolley@yahoo.com Charlottesville, VA