Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
From: cgf AT cygnus DOT com (Chris Faylor)
Newsgroups: cygnus.gnu-win32
Subject: Re: strchr bug?
Date: 9 Nov 1999 21:03:34 GMT
Organization: Cygnus Solutions
Lines: 99
Message-ID: <80a276$2gi$1@cronkite.cygnus.com>
References: <upuxjq1tj DOT fsf AT 1c DOT ru>
NNTP-Posting-Host: rtl.cygnus.com
X-Newsreader: trn 4.0-test70 (17 January 1999)
To: cygwin AT sourceware DOT cygnus DOT com
DJ-Gateway: from newsgroup cygnus.gnu-win32

In article <upuxjq1tj DOT fsf AT 1c DOT ru>, Vadim Egorov  <egorovv AT 1c DOT ru> wrote:
>Hello,
>While porting ElectricFence to cygwin I encountered a problem
>with strchr implementation in newlib.
>When it finds character occurance near the end of string it seems 
>to access (sometimes) memory past the end of string. When the memory
>just after the end of string is unaccessible it causes access violation.
>This can be reproduced by the following program:
>
>-------------- test.cc --------------
>#include <string.h>
>#include <windows.h>
>char pattern[] = "::\0";
>
>int main()
>{
>    DWORD dw;
>    int len = 4;
>    if (sizeof(pattern) != len)
>        return 1;
>    char* base = (char*)VirtualAlloc(0, 0x10000, MEM_COMMIT, PAGE_READWRITE);
>    char* end = base + 4096;
>    if (!VirtualProtect(end, 4096, PAGE_NOACCESS, &dw))
>        return 1;
>    char* p = end - len;
>    memcpy(p, pattern, len);
>    p++;
>    p = strchr(p, ':');
>    return 0;
>}
>-------------- test.cc --------------
>
>What confuses is that it happens only when optimization is turned on:
>gcc test.cc -O2 -o test
>I tried it with gcc 2.95 and 2.95.2 and recent cygwin snapshots.
>Any idea?

Thanks for the bug report and especially for the test case.  I've
forwarded this to our newlib development team and they've come up
with a fix.  It is below.

This will show up in the next snapshot as well.

-chris

----- Forwarded message from J. Johnston" <jjohnstn AT cygnus DOT com> -----
To: Chris Faylor <cgf AT cygnus DOT com>
Subject: Re: [egorovv AT 1c DOT ru: strchr bug?]

Chris,

I have identified the problem in newlib/libc/machine/i386/strchr.S 
and have checked a patch into devo.  I have attached the patch
if you need to send it to the user prior to your nightly build.

-- Jeff J.

> ----- Forwarded message from Vadim Egorov <egorovv AT 1c DOT ru> -----
> [snip]
> 
> ----- End forwarded message -----
--------------851B2C2FBABC35E4F80FBDE7
Content-Type: text/plain; charset=us-ascii;
 name="strchr.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="strchr.patch"

Index: strchr.S
===================================================================
RCS file: /cvs/cvsfiles/devo/newlib/libc/machine/i386/strchr.S,v
retrieving revision 1.1
diff -c -p -r1.1 strchr.S
*** strchr.S	1998/11/30 22:03:46	1.1
--- strchr.S	1999/11/09 17:23:21
*************** SYM (strchr):
*** 24,30 ****
  
  #ifndef __OPTIMIZE_SIZE__	
  /* check if string is aligned, if not do check one byte at a time */
! 	testb $3,al
  	jne L9
  
  /* create 4 byte mask which is just the desired byte repeated 4 times */
--- 24,30 ----
  
  #ifndef __OPTIMIZE_SIZE__	
  /* check if string is aligned, if not do check one byte at a time */
! 	test $3,edi
  	jne L9
  
  /* create 4 byte mask which is just the desired byte repeated 4 times */

--------------851B2C2FBABC35E4F80FBDE7--


-- 
cgf AT cygnus DOT com
http://www.cygnus.com/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com