GNU bug report logs -
#19420
intermittent segfault using grep -P
Previous Next
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.
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):
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):
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):
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):
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):
[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):
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):
[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):
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):
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):
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 2 years and 88 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.