GNU bug report logs -
#21755
new snapshot available: grep-2.21.82-fbc5
Previous Next
Reported by: Jim Meyering <jim <at> meyering.net>
Date: Sun, 25 Oct 2015 16:28:02 UTC
Severity: normal
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21755 in the body.
You can then email your comments to 21755 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#21755; Package
grep.
(Sun, 25 Oct 2015 16:28:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jim Meyering <jim <at> meyering.net>:
New bug report received and forwarded. Copy sent to
bug-grep <at> gnu.org.
(Sun, 25 Oct 2015 16:28:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
grep snapshot:
http://meyering.net/grep/grep-ss.tar.xz 1.3 MB
http://meyering.net/grep/grep-ss.tar.xz.sig
http://meyering.net/grep/grep-2.21.82-fbc5.tar.xz
Changes in grep since 2.21.78-7da30:
Jim Meyering (4):
tests: avoid spurious failure on OpenBSD 5.8
maint: NEWS: correct/amend
gnulib: update to latest, for portability fixes
gnulib: update to latest
Changes in gnulib since 2.21.78-7da30:
* gnulib 5513b40...956fa54 (50):
> stdalign: port to Sun C 5.9
> autoupdate
> update from texinfo
> autoupdate
> time_rz: fix comment about tzalloc
> update from texinfo
> stdalign: work around pre-4.9 GCC x86 bug
> maint.mk: sc_tight_scope: remove extraneous expressions
> time_rz: return NULL if localtime_r fails
> fts: port to C11 alignof
> time_rz: avoid warning from bleeding-edge gcc's -Wnonnull
> maint.mk: _gl_TS_function_match: fix "extern" name extracting regexp
> maint.mk: sc_tight_scope: factor and support OS X
> ChangeLog: fix typo: s/cound/count/
> safe-alloc-tests: fix typo in license header
> copy-file: fix mem leak in error case
> localename: control langinfo.h inclusion
> update from texinfo
> binary-io, math, pthread, sys_socket, u64, unistd: port to strict C
> accept4-tests: fix to avoid non portable flags
> update from texinfo
> update from texinfo
> gnulib-tool: fix tests of 'extensions' module
> unicase/locale-language: fix typo in utf-8 cookie
> autoupdate
> xalloc: do not worry about GCC 5 warning on 32 bit
> xalloc: avoid GCC 5.1 warning on 32 bit
> uniname/uniname-tests: avoid compiler warnings
> autoupdate
> mountlist: clean up of variable duplication
> c-ctype: do not worry about EBCDIC + char signed
> c-ctype: port better to z/OS EBCDIC
> gnulib-common.m4: fix gl_PROG_AR_RANLIB/AM_PROG_AR clash
> sockets: MS Windows initalization fixes
> gc: fix detection of installed libgcrypt version
> c-ctype: rewrite to use inline functions
> fnmatch: add one more coding cookie
> maint: add coding cookies to non-ASCII sources
> gitlog-to-changelog: trim only trailing whitespaces
> Test that c_iscntrl agrees with iscntrl, etc.
> c-ctype: improve c_isascii testing
> Fix ChangeLog typo
> savewd: remove SAVEWD_CHDIR_READABLE
> Update ChangeLog to match previous patch.
> c-ctype: support EBCDIC-style c_isascii
> c-ctype: assume EBCDIC 1047 for c_iscntrl
> * modules/c-ctype (Depends-on): Add verify.
> c-ctype: port better to EBCDIC
> nanosleep: fix return code for interrupted replacement
> autoupdate
Information forwarded
to
bug-grep <at> gnu.org:
bug#21755; Package
grep.
(Sun, 25 Oct 2015 17:05:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 21755 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Jim Meyering wrote:
> grep snapshot:
> http://meyering.net/grep/grep-ss.tar.xz 1.3 MB
> http://meyering.net/grep/grep-ss.tar.xz.sig
> http://meyering.net/grep/grep-2.21.82-fbc5.tar.xz
I tested in a linuxfromscratch environment. See
http://www.linuxfromscratch.org/lfs/view/stable/chapter03/packages.html
for a list of all packages.
GNU grep 2.21.82-fbc5: tests/test-suite.log
=================================================
# TOTAL: 95
# PASS: 88
# SKIP: 4
# XFAIL: 2
# FAIL: 1
# XPASS: 0
# ERROR: 0
For check expensive, I got:
# TOTAL: 95
# PASS: 91
# SKIP: 1
# XFAIL: 2
# FAIL: 1
# XPASS: 0
# ERROR: 0
Logs attached.
-- Bruce
[expensive.log (text/plain, attachment)]
[check.log (text/plain, attachment)]
Information forwarded
to
bug-grep <at> gnu.org:
bug#21755; Package
grep.
(Sun, 25 Oct 2015 18:43:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 21755 <at> debbugs.gnu.org (full text, mbox):
Hi Jim,
On Sun, 25 Oct 2015 09:27:01 -0700
Jim Meyering <jim <at> meyering.net> wrote:
> grep snapshot:
> http://meyering.net/grep/grep-ss.tar.xz 1.3 MB
> http://meyering.net/grep/grep-ss.tar.xz.sig
> http://meyering.net/grep/grep-2.21.82-fbc5.tar.xz
>
> Changes in grep since 2.21.78-7da30:
>
> Jim Meyering (4):
> tests: avoid spurious failure on OpenBSD 5.8
> maint: NEWS: correct/amend
> gnulib: update to latest, for portability fixes
> gnulib: update to latest
>
This is what I get on Mageia Linux x86-64 version 6:
============================================================================
Testsuite summary for GNU grep 2.21.82-fbc5
============================================================================
# TOTAL: 139
# PASS: 130
# SKIP: 9
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
Regards,
Shlomi Fish
>
> Changes in gnulib since 2.21.78-7da30:
>
> * gnulib 5513b40...956fa54 (50):
> > stdalign: port to Sun C 5.9
> > autoupdate
> > update from texinfo
> > autoupdate
> > time_rz: fix comment about tzalloc
> > update from texinfo
> > stdalign: work around pre-4.9 GCC x86 bug
> > maint.mk: sc_tight_scope: remove extraneous expressions
> > time_rz: return NULL if localtime_r fails
> > fts: port to C11 alignof
> > time_rz: avoid warning from bleeding-edge gcc's -Wnonnull
> > maint.mk: _gl_TS_function_match: fix "extern" name extracting regexp
> > maint.mk: sc_tight_scope: factor and support OS X
> > ChangeLog: fix typo: s/cound/count/
> > safe-alloc-tests: fix typo in license header
> > copy-file: fix mem leak in error case
> > localename: control langinfo.h inclusion
> > update from texinfo
> > binary-io, math, pthread, sys_socket, u64, unistd: port to strict C
> > accept4-tests: fix to avoid non portable flags
> > update from texinfo
> > update from texinfo
> > gnulib-tool: fix tests of 'extensions' module
> > unicase/locale-language: fix typo in utf-8 cookie
> > autoupdate
> > xalloc: do not worry about GCC 5 warning on 32 bit
> > xalloc: avoid GCC 5.1 warning on 32 bit
> > uniname/uniname-tests: avoid compiler warnings
> > autoupdate
> > mountlist: clean up of variable duplication
> > c-ctype: do not worry about EBCDIC + char signed
> > c-ctype: port better to z/OS EBCDIC
> > gnulib-common.m4: fix gl_PROG_AR_RANLIB/AM_PROG_AR clash
> > sockets: MS Windows initalization fixes
> > gc: fix detection of installed libgcrypt version
> > c-ctype: rewrite to use inline functions
> > fnmatch: add one more coding cookie
> > maint: add coding cookies to non-ASCII sources
> > gitlog-to-changelog: trim only trailing whitespaces
> > Test that c_iscntrl agrees with iscntrl, etc.
> > c-ctype: improve c_isascii testing
> > Fix ChangeLog typo
> > savewd: remove SAVEWD_CHDIR_READABLE
> > Update ChangeLog to match previous patch.
> > c-ctype: support EBCDIC-style c_isascii
> > c-ctype: assume EBCDIC 1047 for c_iscntrl
> > * modules/c-ctype (Depends-on): Add verify.
> > c-ctype: port better to EBCDIC
> > nanosleep: fix return code for interrupted replacement
> > autoupdate
>
>
>
--
-----------------------------------------------------------------
Shlomi Fish http://www.shlomifish.org/
List of Text Processing Tools - http://shlom.in/text-proc
God is Chuck Norris, for extremely large values of God.
— http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/
Please reply to list if it's a mailing list post - http://shlom.in/reply .
Information forwarded
to
bug-grep <at> gnu.org:
bug#21755; Package
grep.
(Sun, 25 Oct 2015 19:57:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 21755 <at> debbugs.gnu.org (full text, mbox):
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).
Information forwarded
to
bug-grep <at> gnu.org:
bug#21755; Package
grep.
(Sun, 25 Oct 2015 21:06:03 GMT)
Full text and
rfc822 format available.
Message #17 received at 21755 <at> debbugs.gnu.org (full text, mbox):
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.
-- Bruce
Information forwarded
to
bug-grep <at> gnu.org:
bug#21755; Package
grep.
(Sun, 25 Oct 2015 21:52:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 21755 <at> debbugs.gnu.org (full text, mbox):
On Sun, Oct 25, 2015 at 2:05 PM, Bruce Dubbs <bruce.dubbs <at> 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"
Information forwarded
to
bug-grep <at> gnu.org:
bug#21755; Package
grep.
(Sun, 25 Oct 2015 22:20:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 21755 <at> debbugs.gnu.org (full text, mbox):
Jim Meyering wrote:
> 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;
> }
Thanks Jim,
I get:
$ gcc print-pcre-version.c -lpcre; ./a.out
8.37 2015-04-28
6 months old does not seem like an 'older' version to me. Actually
pcre2-10.10 is older than that. There is one more recent version of
pcre2-10.20 as of July 2nd.
> 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"
I'm not sure what advantage those switches would give. I have
pcre-config --cflags = (null)
pcre-config --libs = -lpcre
pcre-config --prefix = /usr
So that line would translate to:
make AM_CFLAGS= AM_LDFLAGS=-lpcre -Wl,-rpath -Wl,/usr/lib
which, if I'm not mistaken, is what the default would be without any
options being passed to make.
The issue appears to be that there is a different pcre2 used by some
distros. I would think that the tests in grep should account for both
pcre and pcre2, at least for a couple of years.
-- Bruce
Information forwarded
to
bug-grep <at> gnu.org:
bug#21755; Package
grep.
(Sun, 25 Oct 2015 22:28:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 21755 <at> debbugs.gnu.org (full text, mbox):
Bruce Dubbs wrote:
> I would think that the tests in grep should account for both pcre and pcre2, at
> least for a couple of years.
Grep currently supports only PCRE. I'd be surprised if it worked with PCRE2.
My test was with PCRE 8.35 with Debian and Ubuntu patches (I'm up-to-date with
Ubuntu 15.10 on x86-64). Yours was with 8.37, I assume with no patches.
Perhaps if I find the time I can try building PCRE 8.37 on Ubuntu 15.10 and see
whether it exhibits the bug, but to be honest I was hoping someone else could
debug this. Perhaps you can try it with 8.35 on linuxfromscratch?
I assume you're doing your test on x86-64? (Sorry, don't recall.)
Information forwarded
to
bug-grep <at> gnu.org:
bug#21755; Package
grep.
(Sun, 25 Oct 2015 23:03:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 21755 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
> Bruce Dubbs wrote:
>> I would think that the tests in grep should account for both pcre and
>> pcre2, at
>> least for a couple of years.
>
> Grep currently supports only PCRE. I'd be surprised if it worked with
> PCRE2.
>
> My test was with PCRE 8.35 with Debian and Ubuntu patches (I'm
> up-to-date with Ubuntu 15.10 on x86-64). Yours was with 8.37, I assume
> with no patches. Perhaps if I find the time I can try building PCRE 8.37
> on Ubuntu 15.10 and see whether it exhibits the bug, but to be honest I
> was hoping someone else could debug this. Perhaps you can try it with
> 8.35 on linuxfromscratch?
Yes, I can do that. The main Upstream repo doesn't have 8.35, but it
was at sourceforge. I installed that:
-rwxr-xr-x 1 root root 762440 Oct 25 17:43 /lib/libpcre.so.1.2.3
but the pcre-jitstack test still aborts with a segfault. I could try
with a smaller pcrejit.txt file if that would help.
OK, I think I have it. I had a default ulimit:
stack size (kbytes, -s) 8192
when I changed that to unlimited, the test passed. More testing and
ulimit -s 16000 fails but ulimit -s 32000 passes.
> I assume you're doing your test on x86-64? (Sorry, don't recall.)
Yes:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 12
On-line CPU(s) list: 0-11
Thread(s) per core: 2
Core(s) per socket: 6
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 63
Model name: Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz
-- Bruce
Information forwarded
to
bug-grep <at> gnu.org:
bug#21755; Package
grep.
(Mon, 26 Oct 2015 02:20:03 GMT)
Full text and
rfc822 format available.
Message #32 received at 21755 <at> debbugs.gnu.org (full text, mbox):
On Sun, Oct 25, 2015 at 4:02 PM, Bruce Dubbs <bruce.dubbs <at> gmail.com> wrote:
> Paul Eggert wrote:
>>
>> Bruce Dubbs wrote:
>>>
>>> I would think that the tests in grep should account for both pcre and
>>> pcre2, at
>>> least for a couple of years.
>>
>>
>> Grep currently supports only PCRE. I'd be surprised if it worked with
>> PCRE2.
>>
>> My test was with PCRE 8.35 with Debian and Ubuntu patches (I'm
>> up-to-date with Ubuntu 15.10 on x86-64). Yours was with 8.37, I assume
>> with no patches. Perhaps if I find the time I can try building PCRE 8.37
>> on Ubuntu 15.10 and see whether it exhibits the bug, but to be honest I
>> was hoping someone else could debug this. Perhaps you can try it with
>> 8.35 on linuxfromscratch?
>
>
> Yes, I can do that. The main Upstream repo doesn't have 8.35, but it was at
> sourceforge. I installed that:
>
> -rwxr-xr-x 1 root root 762440 Oct 25 17:43 /lib/libpcre.so.1.2.3
>
> but the pcre-jitstack test still aborts with a segfault. I could try with a
> smaller pcrejit.txt file if that would help.
>
> OK, I think I have it. I had a default ulimit:
>
> stack size (kbytes, -s) 8192
>
> when I changed that to unlimited, the test passed. More testing and ulimit
> -s 16000 fails but ulimit -s 32000 passes.
Thanks for investigating.
I wonder why your libpcre-8.37 needs so much stack and mine
(built from the release tarball by me, with no patch) segfaults only
when I restrict stack to less than about 50 KB.
I.e.,this exits with status 1:
( ulimit -s 50; LC_ALL=C src/grep -P -n '^([/](?!/)|[^/])*~/.*' pcrejit.txt )
but changing to a ulimit of 40 KB, it consistently segfaults.
That also jibes with what valgrind --tool=massif --stacks=yes reports.
Information forwarded
to
bug-grep <at> gnu.org:
bug#21755; Package
grep.
(Mon, 26 Oct 2015 02:51:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 21755 <at> debbugs.gnu.org (full text, mbox):
Jim Meyering wrote:
> Thanks for investigating.
> I wonder why your libpcre-8.37 needs so much stack and mine
> (built from the release tarball by me, with no patch) segfaults only
> when I restrict stack to less than about 50 KB.
> I.e.,this exits with status 1:
>
> ( ulimit -s 50; LC_ALL=C src/grep -P -n '^([/](?!/)|[^/])*~/.*' pcrejit.txt )
>
> but changing to a ulimit of 40 KB, it consistently segfaults.
> That also jibes with what valgrind --tool=massif --stacks=yes reports.
$ valgrind --tool=massif --stacks=yes ./grep -P -n
'^([/](?!/)|[^/])*~/.*' pcrejit.txt
==27974== Massif, a heap profiler
==27974== Copyright (C) 2003-2015, and GNU GPL'd, by Nicholas Nethercote
==27974== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==27974== Command: ./grep -P -n ^([/](?!/)|[^/])*~/.* pcrejit.txt
==27974==
==27974== Stack overflow in thread #1: can't grow stack to 0xffe801000
==27974==
==27974== Process terminating with default action of signal 11 (SIGSEGV)
==27974== Access not within mapped region at address 0xFFE801E70
==27974== Stack overflow in thread #1: can't grow stack to 0xffe801000
==27974== at 0x4E3E700: ??? (in /lib/libpcre.so.1.2.5)
==27974== If you believe this happened as a result of a stack
==27974== overflow in your program's main thread (unlikely but
==27974== possible), you can try to increase the size of the
==27974== main thread stack using the --main-stacksize= flag.
==27974== The main thread stack size used in this run was 8388608.
==27974== Stack overflow in thread #1: can't grow stack to 0xffe801000
==27974==
==27974== Process terminating with default action of signal 11 (SIGSEGV)
==27974== Access not within mapped region at address 0xFFE801E58
==27974== Stack overflow in thread #1: can't grow stack to 0xffe801000
==27974== at 0x4A24640: _vgnU_freeres (vg_preloaded.c:58)
==27974== If you believe this happened as a result of a stack
==27974== overflow in your program's main thread (unlikely but
==27974== possible), you can try to increase the size of the
==27974== main thread stack using the --main-stacksize= flag.
==27974== The main thread stack size used in this run was 8388608.
==27974==
Segmentation fault
$ ulimit -s unlimited
$ valgrind --tool=massif --main-stacksize=21000000 --stacks=yes ./grep
-P -n '^([/](?!/)|[^/])*~/.*' pcrejit.txt
==28034== Massif, a heap profiler
==28034== Copyright (C) 2003-2015, and GNU GPL'd, by Nicholas Nethercote
==28034== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==28034== Command: ./grep -P -n ^([/](?!/)|[^/])*~/.* pcrejit.txt
==28034==
==28034==
But if I change --main-stacksize to 20000000 it segfaults.
Using libpcre.so.1.2.5 (pcre-8.37).
-- Bruce
Information forwarded
to
bug-grep <at> gnu.org:
bug#21755; Package
grep.
(Mon, 26 Oct 2015 03:47:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 21755 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Oct 25, 2015 at 09:27:01AM -0700, Jim Meyering wrote:
>grep snapshot:
> http://meyering.net/grep/grep-ss.tar.xz 1.3 MB
> http://meyering.net/grep/grep-ss.tar.xz.sig
> http://meyering.net/grep/grep-2.21.82-fbc5.tar.xz
>
>Changes in grep since 2.21.78-7da30:
>
>Jim Meyering (4):
> tests: avoid spurious failure on OpenBSD 5.8
> maint: NEWS: correct/amend
> gnulib: update to latest, for portability fixes
> gnulib: update to latest
>
>
>Changes in gnulib since 2.21.78-7da30:
>
>* gnulib 5513b40...956fa54 (50):
> <snip>
I'm testing on Debian stretch, with GCC 5.2 -- on a default build, all
tests pass (including check-expensive), but adding
'CFLAGS=-fsanitize=address' results in a lot of test failures. After
some investigation I found this was due to it detecting memory leaks
(though it was a bit tricky to determine that because the detection
happened after clean_up_stdout() closed stderr, so the actual report
took a bit of fishing to extract).
With the attached patch applied all the grep tests pass, though the
gnulib-tests suite still hits 12 failures (gnulib-tests/test-suite.log
also attached) -- I could perhaps look into those myself, but I figure
someone more familiar with the codebase can probably fix them much more
quickly than I could.
Zev
[0001-dfa-plug-a-memory-leak-in-dfamust.patch (text/x-diff, attachment)]
[gnulib-test-suite.log.gz (application/gzip, attachment)]
Information forwarded
to
bug-grep <at> gnu.org:
bug#21755; Package
grep.
(Tue, 27 Oct 2015 09:07:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 21755 <at> debbugs.gnu.org (full text, mbox):
Bruce Dubbs wrote:
>> ( ulimit -s 50; LC_ALL=C src/grep -P -n '^([/](?!/)|[^/])*~/.*' pcrejit.txt )
>>
>> but changing to a ulimit of 40 KB, it consistently segfaults.
>> That also jibes with what valgrind --tool=massif --stacks=yes reports.
>
> $ valgrind --tool=massif --stacks=yes ./grep -P -n '^([/](?!/)|[^/])*~/.*'
> pcrejit.txt
Maybe the LC_ALL=C in Jim's test explains the differing behaviors?
Information forwarded
to
bug-grep <at> gnu.org:
bug#21755; Package
grep.
(Tue, 27 Oct 2015 15:50:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 21755 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
> Bruce Dubbs wrote:
>>> ( ulimit -s 50; LC_ALL=C src/grep -P -n '^([/](?!/)|[^/])*~/.*'
>>> pcrejit.txt )
>>>
>>> but changing to a ulimit of 40 KB, it consistently segfaults.
>>> That also jibes with what valgrind --tool=massif --stacks=yes reports.
>>
>> $ valgrind --tool=massif --stacks=yes ./grep -P -n
>> '^([/](?!/)|[^/])*~/.*'
>> pcrejit.txt
>
> Maybe the LC_ALL=C in Jim's test explains the differing behaviors?
I don't think so. I do not have any LC/LANG/LANGUAGE variables defined.
One thing that may be different is that I used
--enable-unicode-properties when building pcre.
http://www.linuxfromscratch.org/blfs/view/svn/general/pcre.html
-- Bruce
Information forwarded
to
bug-grep <at> gnu.org:
bug#21755; Package
grep.
(Sun, 01 Nov 2015 23:43:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 21755 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Oct 27, 2015 at 8:49 AM, Bruce Dubbs <bruce.dubbs <at> gmail.com> wrote:
> Paul Eggert wrote:
>>
>> Bruce Dubbs wrote:
>>>>
>>>> ( ulimit -s 50; LC_ALL=C src/grep -P -n '^([/](?!/)|[^/])*~/.*'
>>>> pcrejit.txt )
>>>>
>>>> but changing to a ulimit of 40 KB, it consistently segfaults.
>>>> That also jibes with what valgrind --tool=massif --stacks=yes reports.
>>>
>>>
>>> $ valgrind --tool=massif --stacks=yes ./grep -P -n
>>> '^([/](?!/)|[^/])*~/.*'
>>> pcrejit.txt
>>
>>
>> Maybe the LC_ALL=C in Jim's test explains the differing behaviors?
>
>
> I don't think so. I do not have any LC/LANG/LANGUAGE variables defined.
> One thing that may be different is that I used
> --enable-unicode-properties when building pcre.
>
> http://www.linuxfromscratch.org/blfs/view/svn/general/pcre.html
Thanks again for helping with this.
I have adjusted the test to retry with unlimited stack size, if possible.
Patch attached. I expect to push that and release grep-2.22 within
the next few hours, so if anyone can try that, I'd appreciate it.
This does not merit another snapshot.
[0001-tests-pcre-jitstack-upon-failure-retry-with-no-stack.patch (text/x-patch, attachment)]
bug closed, send any further explanations to
21755 <at> debbugs.gnu.org and Jim Meyering <jim <at> meyering.net>
Request was from
Paul Eggert <eggert <at> cs.ucla.edu>
to
control <at> debbugs.gnu.org.
(Thu, 31 Dec 2015 08:56:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 28 Jan 2016 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 8 years and 84 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.