Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 17996 invoked by uid 500); 18 Aug 2001 07:34:14 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 17976 invoked from network); 18 Aug 2001 07:34:10 -0000 Message-Id: <200108180734.f7I7YCB29904@silk.apana.org.au> From: "Brian Havard" To: "new-httpd@apache.org" Date: Sat, 18 Aug 2001 17:34:12 +1000 (EST) Reply-To: "Brian Havard" Priority: Normal X-Mailer: PMMail 2.10.1999 for OS/2 Warp 4.05 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: cvs commit: httpd-2.0/modules/filters mod_include.c X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Status: O X-Status: X-Keywords: X-UID: 785 On 17 Aug 2001 17:21:16 -0400, Jeff Trawick wrote: >trawick@apache.org writes: > >> trawick 01/08/17 13:41:15 >> >> Modified: modules/filters mod_include.c >> Log: >> Fix a problem in mod_include when we reached the BYTE_COUNT_THRESHOLD >> after parsing the first part of the tag. We could get errors like >> >> [error] [client 127.0.0.1] unknown directive " >At this point, I think a certain class of errors are taken care of >(encountering BYTE_COUNT_THRESHOLD at different places within the >tag). I've tested tag offsets from 1 to 10000 bytes and some selected >ones above that > >I don't think we handle a tag longer than BYTE_COUNT_THRESHOLD. >Paul mentioned off-line that he would look into that. I doubt that is >necessary for the short term. I'm seeing a SEGV when parsing a file > 8192 bytes (even 1 byte greater). Notable points: - Stack is trashed, can't get a backtrace - The client receives the full & correct response - Appears to be a call to a null function pointer (EIP=0 in trap log), destroying the buckets. It could just be a symptom of other corruption though. - It still crashes even if the output is shorter than 8192 due to tag parsing. This is on OS/2 where there's no mmap or sendfile. We've seen before that the non-mmap code path is different enough to have its own bugs.... -- ______________________________________________________________________________ | Brian Havard | "He is not the messiah! | | brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian | ------------------------------------------------------------------------------