On Sun, Oct 25, 2015 at 2:05 PM, Bruce Dubbs <bruce.du...@gmail.com> wrote:
> Paul Eggert wrote:
>>
>> Bruce Dubbs wrote:
>>>
>>>
>>> I tested in a linuxfromscratch environment. See
>>> http://www.linuxfromscratch.org/lfs/view/stable/chapter03/packages.html
>>> for
>>> a
>>> list of all packages.
>>
>>
>> You're getting one unexpected failure, from pcre-jitstack. That package
>> list doesn't mention which version of libpcre the build used; do you
>> happen to know what it was? I'm not seeing the problem on x86-64 Ubuntu
>> 15.10, which uses libpcre3 2:8.35-7.1ubuntu1. Most likely the problem
>> you're seeing is due to some bug in libpcre (which we have no control
>> over) or in the way we interface to libpcre (which we'd want to fix, at
>> least by refusing to link to the older libpcre implementation).
>
>
> In a base LFS system, pcre is not installed at all. I went back and tested
> on a minimal LFS system and got:
>
> Testsuite summary for GNU grep 2.21.82-fbc5
> ============================================================================
> # TOTAL: 95
> # PASS: 78
> # SKIP: 15
> # XFAIL: 2
> # FAIL: 0
> # XPASS: 0
> # ERROR: 0
>
> and
>
> # TOTAL: 139
> # PASS: 132
> # SKIP: 7
> # XFAIL: 0
> # FAIL: 0
> # XPASS: 0
> # ERROR: 0
>
> My earlier report was for a fairly complete BLFS system and that did have
> pcre-8.37 installed:
>
> http://www.linuxfromscratch.org/blfs/view/svn/general/pcre.html
>
> Checking upstream, that version was released 4/28/2015. Note that we are
> not using pcre2 (maybe we should).
>
> Just to double check I rebuilt pcre, but I still get the failure in
> pcre-jitstack.
>
> As you probably noticed, the command
>
> LC_ALL=C grep -P -n '^([/](?!/)|[^/])*~/.*' pcrejit.txt
>
> gave a segmentation fault.
>
> Running gdb, I get:
>
> Starting program: /usr/src/lfs-7.8-sources/grep-2.21.82-fbc5/src/grep -P -n
> '^([/](?!/)|[^/])*~/.*' pcrejit.txt
>
> Program received signal SIGSEGV, Segmentation fault.
> match (
> eptr=0x629ff7 "aaaaaaaaaa/aaaa/", 'a' <repeats 19 times>,
> "/aaaa/aaaaaa/aa/aaaaa/", 'a' <repeats 13 times>, "/aaaa/", 'a' <repeats 21
> times>, "/aaaa/aaaaaa/aa/aaaaa/", 'a' <repeats 13 times>, "/aaaa/", 'a'
> <repeats 17 times>, "/aaaa/aaaaaa/aa/aaaaa/", 'a' <repeats 13 times>,
> "/aaaa/aaaa"..., ecode=0x62759a "\035/~",
> mstart=0x628000 "/aaaa/aaaaaa/aa/aaaaa/", 'a' <repeats 13 times>,
> "/aa/", 'a' <repeats 34 times>, "/aaaa/aaaaaa/aa/aaaaa/", 'a' <repeats 13
> times>, "/aa/", 'a' <repeats 22 times>, "/aaaa/aaaaaa/aa/aaaaa/", 'a'
> <repeats 13 times>, "/aa/", 'a' <repeats 27 times>..., offset_top=4,
> md=0x7fffffffd1b0, eptrb=0x0, rdepth=16368) at pcre_exec.c:516
>
>
> I cannot follow what is going on beyond that. I suspect it is an issue with
> pcre vs pcre2. Perhaps your test should look for a specific version of
> pcre.
Thanks for testing.
However, that failure probably indicates that you are running
a binary that uses an older version of libpcre. Compare the results
of these commands on a Centos6 system:
$ gcc print-pcre-version.c -lpcre; ./a.out
7.8 2008-09-05
$ gcc print-pcre-version.c $(pcre-config --libs) \
-Wl,-rpath -Wl,$(pcre-config --prefix)/lib && ./a.out
8.37 2015-04-28
$ cat print-pcre-version.c
#include <stdio.h>
char *pcre_version(void);
int
main ()
{
puts (pcre_version());
return 0;
}
I.e., if I don't take special measures, I end up using the much
older system-provided version than the one that I installed to
work around this problem.
I too saw the symptom of a segfault in "match", before I
switched to building with these options:
make AM_CFLAGS="$(pcre-config --cflags)" AM_LDFLAGS="$(pcre-config
--libs) -Wl,-rpath -Wl,$(pcre-config --prefix)/lib"
