X-Spam-Check-By: sourceware.org Message-ID: <45BA8699.D1E474EA@dessent.net> Date: Fri, 26 Jan 2007 14:54:17 -0800 From: Brian Dessent X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) MIME-Version: 1.0 To: cygwin@cygwin.com CC: bug-grep@gnu.org Subject: Re: grep -P segfault References: <20070126220628.76419.qmail@hyperreal.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin@cygwin.com Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Mike Brown wrote: > Can anyone reproduce this? > > This is on a fairly small Cygwin installation on WinXP, last updated 4 days > ago. > > $ echo hello | grep -P '\n' > hello > > ? hello > > ? hello > 4 [main] grep 3280 _cygtls::handle_exceptions: Error while dumping state > (probably corrupted stack) > Segmentation fault (core dumped) The crash is due to this in grep's search.c:Pexecute(): 697 /* Narrow down to the line we've found. */ 698 char const *beg = buf + sub[0]; 699 char const *end = buf + sub[1]; 700 char const *buflim = buf + size; 701 char eol = eolbyte; 702 if (!exact) 703 { 704 end = memchr (end, eol, buflim - end); 705 end++; 706 while (buf < beg && beg[-1] != eol) 707 --beg; 708 } 709 710 *match_size = end - beg; 711 return beg - buf; Right before calling memchr, beg points to the first byte in the string "hello\n", end points to the \n character, and so does buflim. Thus (buflim - end) is zero, and memchr returns NULL. From there match_size is miscalculated and from there it's all downhill. The test for EOL should be skipped if buflim == end. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/