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