GNU bug report logs - #19420
intermittent segfault using grep -P

Previous Next

Package: grep;

Reported by: "J.P. Hendrix" <bug-grep-gnu.org <at> linformatronics.nl>

Date: Sat, 20 Dec 2014 19:14:01 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19420 in the body.
You can then email your comments to 19420 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-grep <at> gnu.org:
bug#19420; Package grep. (Sat, 20 Dec 2014 19:14:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to "J.P. Hendrix" <bug-grep-gnu.org <at> linformatronics.nl>:
New bug report received and forwarded. Copy sent to bug-grep <at> gnu.org. (Sat, 20 Dec 2014 19:14:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "J.P. Hendrix" <bug-grep-gnu.org <at> linformatronics.nl>
To: bug-grep <at> gnu.org
Subject: intermittent segfault using grep -P
Date: Sat, 20 Dec 2014 10:55:24 +0100
When using the following command, *most* of the time I get a 
Segmentation fault (10 out of 16 times):

€ cat grepTxt | grep -P 'b(?:(?!tom).)+'
Segmentation fault (core dumped)

This happens with the  grep version that came with my Linux installation:

€ grep -V
grep (GNU grep) 2.16

I am on:

NAME="Ubuntu"
VERSION="14.04.1 LTS, Trusty Tahr"

But also compiled grep from sources 
(http://ftp.gnu.org/gnu/grep/grep-2.21.tar.xz) with the same problem.

libpcre3:amd64; libpcre3:i386; libpcre3-dev:amd64; libpcrecpp0:amd64 are 
all 1:8.31-2ubuntu2

I tried to reduce the regex and the text as much as possible to still 
reproduce the issue most of the time, unfortunately the text is still 
16893 bytes long. As I don't know if it is OK to attach such a long 
file, I put it on pastebin, but will expire in a month.

http://pastebin.com/download.php?i=jsHskMAA

Please advise.

Kind regards,

JP




Information forwarded to bug-grep <at> gnu.org:
bug#19420; Package grep. (Sat, 20 Dec 2014 20:58:02 GMT) Full text and rfc822 format available.

Message #8 received at 19420 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "J.P. Hendrix" <bug-grep-gnu.org <at> linformatronics.nl>, 
 19420 <at> debbugs.gnu.org
Subject: Re: bug#19420: intermittent segfault using grep -P
Date: Sat, 20 Dec 2014 12:57:43 -0800
I can't reproduce the problem on Ubuntu 14.10 (x86-64) or Fedora 20 (x86-64), 
with either the bundled grep or with GNU grep 2.21.

What locale are you running in?  What's the output of the 'locale' command?

It could be a bug in grep, or in libpcre, or somewhere else.  Ubuntu 14.10 is 
running libpcre3 1:8.35-3ubuntu1.  I vaguely recall that they're doing something 
funky to prevent grep from depending on libpcre while still supporting -P, but I 
don't recall the details.




Information forwarded to bug-grep <at> gnu.org:
bug#19420; Package grep. (Sat, 20 Dec 2014 21:00:03 GMT) Full text and rfc822 format available.

Message #11 received at 19420 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "J.P. Hendrix" <bug-grep-gnu.org <at> linformatronics.nl>, 
 19420 <at> debbugs.gnu.org
Subject: Re: bug#19420: intermittent segfault using grep -P
Date: Sat, 20 Dec 2014 12:59:45 -0800
One more thing.  It's odd that you get a segfault only 10 times out of 16.  So 
another possibility is that you have a hardware problem.  Can you reproduce the 
bug on some other machine?




Information forwarded to bug-grep <at> gnu.org:
bug#19420; Package grep. (Sun, 21 Dec 2014 00:57:02 GMT) Full text and rfc822 format available.

Message #14 received at 19420 <at> debbugs.gnu.org (full text, mbox):

From: Norihiro Tanaka <noritnk <at> kcn.ne.jp>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 19420 <at> debbugs.gnu.org, "J.P. Hendrix" <bug-grep-gnu.org <at> linformatronics.nl>
Subject: Re: bug#19420: intermittent segfault using grep -P
Date: Sun, 21 Dec 2014 09:56:38 +0900
In addition, please recompile grep with `-g' and if it is reproduced,
get backtrace from a core file with gdb and send it to us.

  $ CFLAGS=-g ./configure OPTIONS
  $ make
  $ cat grepTxt | grep -P 'b(?:(?!tom).)+'
  $ gdb src/grep core.*

  (gdb) bt





Information forwarded to bug-grep <at> gnu.org:
bug#19420; Package grep. (Sun, 21 Dec 2014 10:34:01 GMT) Full text and rfc822 format available.

Message #17 received at 19420 <at> debbugs.gnu.org (full text, mbox):

From: "J.P. Hendrix" <bug-grep-gnu.org <at> linformatronics.nl>
To: Paul Eggert <eggert <at> cs.ucla.edu>, 19420 <at> debbugs.gnu.org, noritnk <at> kcn.ne.jp
Subject: Re: bug#19420: intermittent segfault using grep -P
Date: Sun, 21 Dec 2014 11:33:17 +0100
[Message part 1 (text/plain, inline)]
My feedback to your questions:

   In addition, please recompile grep with `-g' and if it is reproduced,
   get backtrace from a core file with gdb and send it to us.

      $ CFLAGS=-g ./configure OPTIONS
      $ make
      $ cat grepTxt | grep -P 'b(?:(?!tom).)+'
      $ gdb src/grep core.*

      (gdb) bt

Recompiling
*# **Core files are not dumped by default, enabling that.*
€ ulimit -c unlimited
€ ulimit -a
core file size          (blocks, -c) unlimited
...

*# Fresh compile*
€ tar xf grep-2.21.tar       # new fresh directory.
€ cd grep-2.21
€ CFLAGS=-g ./configure --prefix=/tmp/segfaultGrep/grep/
...
€ make
...
€ cat ../../grepTxt | ./src/grep -qP 'b(?:(?!tom).)+'
../bin/grep: warning: GREP_OPTIONS is deprecated; please use an alias or 
script
Segmentation fault (core dumped)

*# Only one core file is found, but not matching 'core.*'**
**# I have no experience with gdb, so I cannot really judge gdb output**
*€ find /tmp/segfaultGrep/ | grep -i core
/tmp/segfaultGrep/grep/grep-2.21/core
€ gdb src/grep core
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
...
This GDB was configured as "x86_64-linux-gnu".
...
Reading symbols from src/grep...done.
[New LWP 1357]
Core was generated by `./src/grep -qP b(?:(?!tom).)+'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fd8a278054a in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
(gdb) bt
#0  0x00007fd8a278054a in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
#1  0x00007fd8a2780ecb in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
#2  0x00007fd8a278dcfa in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
#3  0x00007fd8a278dcfa in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
#4  0x00007fd8a278dcfa in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
...
#16890 0x00007fd8a278dcfa in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
#16891 0x00007fd8a278dcfa in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
#16892 0x00007fd8a278dcfa in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
#16893 0x00007fd8a2791221 in pcre_exec () from 
/lib/x86_64-linux-gnu/libpcre.so.3
#16894 0x000000000041621d in Pexecute (
    buf=0x13fc000 
"b3VuZDwvaDE+Iik7fQoKJGxhbmd1YWdlPSdlbmcnOwoKJGF1dGggPSAwOwoKJG5hbWU9Jyc7IAokcGFzcz0nJzsKCi8vcnVfUlUsIC8vcnVfUlUuY3AxMjUxLCAvL3J1X1JVLmlzbzg4NTk1LCAvL3J1X1JVLmtvaThyLCAvL3J1X1JVLnV0ZjgKQHNldGxvY2FsZShM"..., 
size=16893, match_size=0x7fffa0333150, start_ptr=0x0) at pcresearch.c:215
#16895 0x0000000000404b95 in grepbuf (
    beg=0x13fc000 
"b3VuZDwvaDE+Iik7fQoKJGxhbmd1YWdlPSdlbmcnOwoKJGF1dGggPSAwOwoKJG5hbWU9Jyc7IAokcGFzcz0nJzsKCi8vcnVfUlUsIC8vcnVfUlUuY3AxMjUxLCAvL3J1X1JVLmlzbzg4NTk1LCAvL3J1X1JVLmtvaThyLCAvL3J1X1JVLnV0ZjgKQHNldGxvY2FsZShM"..., 
lim=0x14001fd "\377") at grep.c:1232
#16896 0x0000000000404fcb in grep (fd=0, st=0x7fffa0333260) at grep.c:1350
#16897 0x0000000000405aad in grepdesc (desc=0, command_line=true) at 
grep.c:1639
#16898 0x0000000000405ca4 in grep_command_line_arg (arg=0x42440e "-") at 
grep.c:1686
#16899 0x000000000040774d in main (argc=4, argv=0x13fa080) at grep.c:2564

*# OK, I guess I know enough about gdb to understand we're missing 
symbols in the output ...*
€ sudo apt-get install libpcre3-dbg
...

*# Working around almost 10 megabyte **output text...*
€ echo bt > bt
€ gdb src/grep core --batch -x bt > /tmp/gdb.out
484     pcre_exec.c: No such file or directory.
*# http://wirespeed.xs4all.nl/media/segfaultGrep/*


I checked on a VM on my laptop, but I can't reproduce the issue there. 
It is 32 bit Ubuntu 14.04.1

I double checked the intermittent behavior on my PC, don't have a reason 
to believe it is hardware related because my system is otherwise stable. 
I found these messages in 'dmesg' after checking the command couple 
times, notice the 'libpcre'.

€ dmesg
[2119696.762373] grep[6488]: segfault at 7fff51de7fe8 ip 
00007f5db8a3454a sp 00007fff51de7fe0 error 6 in 
*libpcre*.so.3.13.1[7f5db8a21000+3d000]
[2119697.880722] grep[6569]: segfault at 7ffffcd28ff8 ip 
00007f00ae1ea53d sp 00007ffffcd28e50 error 6 in 
libpcre.so.3.13.1[7f00ae1d7000+3d000]
[2119698.811133] grep[6646]: segfault at 7fff6252fec8 ip 
00007f0c7545754a sp 00007fff6252fec0 error 6 in 
libpcre.so.3.13.1[7f0c75444000+3d000]
[2119699.674442] grep[6708]: segfault at 7fff5fdcdee8 ip 
00007fb27fa3b54a sp 00007fff5fdcdee0 error 6 in 
libpcre.so.3.13.1[7fb27fa28000+3d000]
[2119700.488632] grep[6770]: segfault at 7fff8fda7ff8 ip 
00007f7791bc5ec6 sp 00007fff8fda8000 error 6 in 
libpcre.so.3.13.1[7f7791bb2000+3d000]
[2119701.274100] grep[6822]: segfault at 7fff29bd8f18 ip 
00007fb0bd44d54a sp 00007fff29bd8f10 error 6 in 
libpcre.so.3.13.1[7fb0bd43a000+3d000]
[2119702.090632] grep[6890]: segfault at 7fffa33f8ee8 ip 
00007fd4b786954a sp 00007fffa33f8ee0 error 6 in 
libpcre.so.3.13.1[7fd4b7856000+3d000]
[2119702.875331] grep[6943]: segfault at 7fffb0b0efd8 ip 
00007fc2a9d7554a sp 00007fffb0b0efd0 error 6 in 
libpcre.so.3.13.1[7fc2a9d62000+3d000]
[2119715.819686] grep[7795]: segfault at 7fff20e78e68 ip 
00007fd5162c854a sp 00007fff20e78e60 error 6 in 
libpcre.so.3.13.1[7fd5162b5000+3d000]
[2119717.595114] grep[7913]: segfault at 7fff2bc21fd8 ip 
00007f30455ec54a sp 00007fff2bc21fd0 error 6 in 
libpcre.so.3.13.1[7f30455d9000+3d000]



I believe I mentioned libpcre3:amd64 1:8.*31*-2ubuntu2 before, but here 
it is for completeness.

€ locale
LANG=en_US.UTF-8
LANGUAGE=en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=en_US.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_ALL=




On 2014-12-20 21:57, Paul Eggert wrote:
> I can't reproduce the problem on Ubuntu 14.10 (x86-64) or Fedora 20 
> (x86-64), with either the bundled grep or with GNU grep 2.21.
>
> What locale are you running in?  What's the output of the 'locale' 
> command?
>
> It could be a bug in grep, or in libpcre, or somewhere else. Ubuntu 
> 14.10 is running libpcre3 1:8.35-3ubuntu1.  I vaguely recall that 
> they're doing something funky to prevent grep from depending on 
> libpcre while still supporting -P, but I don't recall the details.
>

[Message part 2 (text/html, inline)]

Information forwarded to bug-grep <at> gnu.org:
bug#19420; Package grep. (Mon, 22 Dec 2014 15:56:01 GMT) Full text and rfc822 format available.

Message #20 received at 19420 <at> debbugs.gnu.org (full text, mbox):

From: Norihiro Tanaka <noritnk <at> kcn.ne.jp>
To: "J.P. Hendrix" <bug-grep-gnu.org <at> linformatronics.nl>
Cc: 19420 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#19420: intermittent segfault using grep -P
Date: Tue, 23 Dec 2014 00:55:02 +0900
It could reproduce as following in Fedora21, RHEL 6.5.

$ cd pcre-8.36
$ CFLAGS=-g ./configure --enable-utf --enable-unicode-properties
$ make
# make install

grep-2.21
$ ./configure
$ make
# make install

By the way, if we enabled to optimize or recompile pcre with --enable-jit
option, it did not reproduced.

However, I see that it is an issue in PRE side.  It reproduces with
following test case without grep frontend.

==
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <pcre.h>

enum { LEN = 15000 };
enum { NSUB = 300 };

int
main ()
{
  char *text = malloc ((LEN + 1) * sizeof *text);
  memset (text, '0', LEN);
  text[LEN] = '\0';
  char const *re = "0(?:(?!foo).)+";
  char const *ep;
  int eo;

  pcre *cre = pcre_compile (re, 0, &ep, &eo, NULL);
  if (!cre)
    exit (EXIT_FAILURE);

  int sub[NSUB];
  pcre_exec (cre, NULL, text, strlen (text), 0, 0, sub, NSUB);

  exit (EXIT_SUCCESS);
}
==





Information forwarded to bug-grep <at> gnu.org:
bug#19420; Package grep. (Mon, 22 Dec 2014 21:33:02 GMT) Full text and rfc822 format available.

Message #23 received at 19420 <at> debbugs.gnu.org (full text, mbox):

From: "J.P. Hendrix" <bug-grep-gnu.org <at> linformatronics.nl>
To: Norihiro Tanaka <noritnk <at> kcn.ne.jp>
Cc: 19420 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#19420: intermittent segfault using grep -P
Date: Mon, 22 Dec 2014 22:32:33 +0100
[Message part 1 (text/plain, inline)]
I'm not a developer, so please bear with me here. You kinda lost me with 
below analysis, but I think I managed to reproduce your findings with a 
bit of Google-magic. Are you saying a bug should be registered with 
pcre.org?

I am reproducing your findings as follows:

€ sudo apt-get install libpcre3-dbg libpcre3-dev   # these were already 
installed.

€ tar xzf pcre-8.36.tar.gz
€ cd pcre-8.36
€ CFLAGS=-g ./configure --enable-utf --enable-unicode-properties 
--prefix=/tmp/segfaultGrep
€ make
€ make install

€ gcc reproduce.c -L/tmp/segfaultGrep/lib -lpcre
€ LD_LIBRARY_PATH=/tmp/segfaultGrep/lib ./a.out; echo $?
Segmentation fault (core dumped)
139

Please check my notes and advice how to go forward.

Kind regards,

JP



On 2014-12-22 16:55, Norihiro Tanaka wrote:
> It could reproduce as following in Fedora21, RHEL 6.5.
>
> $ cd pcre-8.36
> $ CFLAGS=-g ./configure --enable-utf --enable-unicode-properties
> $ make
> # make install
>
> grep-2.21
> $ ./configure
> $ make
> # make install
>
> By the way, if we enabled to optimize or recompile pcre with --enable-jit
> option, it did not reproduced.
>
> However, I see that it is an issue in PRE side.  It reproduces with
> following test case without grep frontend.
>
> ==
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <pcre.h>
>
> enum { LEN = 15000 };
> enum { NSUB = 300 };
>
> int
> main ()
> {
>    char *text = malloc ((LEN + 1) * sizeof *text);
>    memset (text, '0', LEN);
>    text[LEN] = '\0';
>    char const *re = "0(?:(?!foo).)+";
>    char const *ep;
>    int eo;
>
>    pcre *cre = pcre_compile (re, 0, &ep, &eo, NULL);
>    if (!cre)
>      exit (EXIT_FAILURE);
>
>    int sub[NSUB];
>    pcre_exec (cre, NULL, text, strlen (text), 0, 0, sub, NSUB);
>
>    exit (EXIT_SUCCESS);
> }
> ==
>
>

[Message part 2 (text/html, inline)]

Information forwarded to bug-grep <at> gnu.org:
bug#19420; Package grep. (Tue, 23 Dec 2014 02:06:02 GMT) Full text and rfc822 format available.

Message #26 received at 19420 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "J.P. Hendrix" <bug-grep-gnu.org <at> linformatronics.nl>, 
 Norihiro Tanaka <noritnk <at> kcn.ne.jp>
Cc: 19420 <at> debbugs.gnu.org
Subject: Re: bug#19420: intermittent segfault using grep -P
Date: Mon, 22 Dec 2014 18:05:35 -0800
J.P. Hendrix wrote:
> Are you saying a bug should be registered with pcre.org?

That's what I'd suggest, yes.  I also can reproduce the bug with Mr. Tanaka's 
recipe on CentOS 6.5 x86-64.  Wow, that's pretty deep recursion that 'match' is 
doing....





Information forwarded to bug-grep <at> gnu.org:
bug#19420; Package grep. (Thu, 25 Dec 2014 08:54:01 GMT) Full text and rfc822 format available.

Message #29 received at 19420 <at> debbugs.gnu.org (full text, mbox):

From: "J.P. Hendrix" <bug-grep-gnu.org <at> linformatronics.nl>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Norihiro Tanaka <noritnk <at> kcn.ne.jp>
Cc: 19420 <at> debbugs.gnu.org
Subject: Re: bug#19420: intermittent segfault using grep -P
Date: Thu, 25 Dec 2014 09:53:01 +0100
FYI: I filed a bug with the pcre prject: 
http://bugs.exim.org/show_bug.cgi?id=1562

On 2014-12-23 03:05, Paul Eggert wrote:
> J.P. Hendrix wrote:
>> Are you saying a bug should be registered with pcre.org?
>
> That's what I'd suggest, yes.  I also can reproduce the bug with Mr. 
> Tanaka's recipe on CentOS 6.5 x86-64.  Wow, that's pretty deep 
> recursion that 'match' is doing....
>
>





Reply sent to Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility. (Wed, 24 Nov 2021 03:04:02 GMT) Full text and rfc822 format available.

Notification sent to "J.P. Hendrix" <bug-grep-gnu.org <at> linformatronics.nl>:
bug acknowledged by developer. (Wed, 24 Nov 2021 03:04:02 GMT) Full text and rfc822 format available.

Message #34 received at 19420-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "J.P. Hendrix" <bug-grep-gnu.org <at> linformatronics.nl>
Cc: 19420-done <at> debbugs.gnu.org, Norihiro Tanaka <noritnk <at> kcn.ne.jp>
Subject: Re: bug#19420: intermittent segfault using grep -P
Date: Tue, 23 Nov 2021 19:03:08 -0800
I'm closing this old Grep bug report, on two grounds:

* I can no longer reproduce the the problem on Fedora 35 x86-64, using 
Norihiro Tanaka's test case <https://bugs.gnu.org/19420#20>. This 
suggests the PCRE library has been fixed.

* GNU Grep has switched to PCRE2, so PCRE bugs shouldn't matter now. See 
<https://bugs.gnu.org/47264>.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 22 Dec 2021 12:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 176 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.