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);
}
==
