Re: [platform-testers] bug#21755: new snapshot available: grep-2.21.82-fbc5

[Jim Meyering]

On Sun, Oct 25, 2015 at 2:05 PM, Bruce Dubbs <address@hidden> 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"