[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#366469: marked as done (grep -i segfaults matching a binary file in zh_CN.GBK locale)

Your message dated Mon, 23 Apr 2007 08:43:11 +0200
with message-id <20070423064310.GA15680@amd64.aurel32.net>
and subject line Bug#366469: grep segfaults
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message --- 
Package: grep
Version: 2.5.1.ds2-4

When the locale is zh_CN.GBK, "grep -i" would produce segment fault
with binary files. For instance:
***
lx@nightingale:~/tmp/tmp$ grep -i readline /bin/bash
Segmentation fault
***

Best
Regards,

LIU Xin

--- End Message ---
--- Begin Message --- 
Version: 2.5-1

On Tue, May 09, 2006 at 09:27:31AM -0400, Justin Pryzby wrote:
> tag 366469 confirmed
> reassign 366469 grep,libc6
> retitle 366469 grep -i segfaults matching a binary file in zh_CN.GBK locale
> thanks
> 
> On Mon, May 08, 2006 at 03:42:38PM -0700, Xin Liu wrote:
> > Package: grep
> > Version: 2.5.1.ds2-4
> > 
> > When the locale is zh_CN.GBK, "grep -i" would produce segment fault
> > with binary files. For instance:
> > ***
> > lx@nightingale:~/tmp/tmp$ grep -i readline /bin/bash
> > Segmentation fault
> > ***
> I can confirm this; thanks for the report.  It looks like it might be
> a glibc bug:
> 
> #0  0xb7eb2c1f in *__GI_memcpy (dstpp=0x8075b48, srcpp=0xbfb7ba24, 
>     len=4294967295) at ../sysdeps/generic/memcpy.c:55
> #1  0xb7ee3aab in build_wcs_upper_buffer (pstr=0xbfb7bbc8)
>     at regex_internal.c:424
> #2  0xb7ee3ee3 in re_string_reconstruct (pstr=0xbfb7bbc8, idx=163, 
>     eflags=<value optimized out>) at regex_internal.c:726
> #3  0xb7eea1cc in re_search_internal (preg=0x8075278, string=0x807e1c5 "", 
>     length=<value optimized out>, start=134699848, range=349, stop=349, 
>     nmatch=1, pmatch=0x8075f78, eflags=0) at regexec.c:797
> #4  0xb7eeb2af in re_search_stub (bufp=0x8075278, string=0x807e1c5 "", 
>     length=349, start=0, range=349, stop=-1, regs=0x8075298, ret_len=0)
>     at regexec.c:454
> #5  0xb7eeb7c3 in __re_search (bufp=0xffffffff, 
>     string=0x8075b48 "ػ��\204������?� length=1073738376, start=0, 
>     range=0, regs=0x0) at regexec.c:318
> #6  0x08058666 in EGexecute ()
> #7  0x0804ab02 in grepbuf ()
> #8  0x0804b4b0 in grepfile ()
> #9  0x0804d0b4 in main ()
> 
> Justin
> 
> 

I am able to reproduce this bug with glibc 2.3.6, but not with glibc
2.5, so I guess this bug is fixed.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

--- End Message ---
Reply to: