GNU bug report logs - #19775
Test failing after the CVE fix

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19775 in the body.
You can then email your comments to 19775 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vladimír Čunát <vcunat <at> gmail.com>
To: bug-grep <at> gnu.org
Subject: Test failing after the CVE fix
Date: Wed, 04 Feb 2015 23:51:09 +0100

[Message part 1 (text/plain, inline)]

Hello!
(Please, CC me with replies.)
After the latest CVE fix I'm getting an assertion failure in tests 
(below). I reproduce that both on latest master (846e7eee8) or with 2.21 
with patch 83a95bd8c8 applied (2.21 itself is OK).


XFAIL: triple-backref
=====================

grep: regexec.c:1401: pop_fail_stack: Assertion `num >= 0' failed.
./triple-backref: line 32:  8135 Aborted                 grep -E 
'(.?)(.?)(.?)\3\2\1' in > out
--- out 2015-02-04 21:41:19.316668595 +0000
+++ in  2015-02-04 21:41:19.316668595 +0000
@@ -0,0 +1 @@
+a


Thanks,
Vladimir

[smime.p7s (application/pkcs7-signature, attachment)]

Message #8 received at 19775 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Vladimír Čunát <vcunat <at> gmail.com>, 
 19775 <at> debbugs.gnu.org
Subject: Re: bug#19775: Test failing after the CVE fix
Date: Wed, 04 Feb 2015 16:56:54 -0800

Vladimír Čunát wrote:
> After the latest CVE fix I'm getting an assertion failure in tests (below). I
> reproduce that both on latest master (846e7eee8) or with 2.21 with patch
> 83a95bd8c8 applied (2.21 itself is OK).
>
>
> XFAIL: triple-backref

XFAIL means it's eXpected to FAIL.  So when the test fails, that means the test 
is working (though 'grep' itself has a bug, of course).

The same XFAIL occurs with grep 2.21 on my platform (Fedora 21 x86-64).  The 
underlying bug is platform-dependent.  I'm a bit surprised you're seeing the bug 
with the latest master but not with 2.21, but it's conceivable you've run into a 
platform dependency, e.g., your grep 2.21 has the bug but the test case doesn't 
suffice to demonstrate it on your platform.

Message #11 received at 19775 <at> debbugs.gnu.org (full text, mbox):

From: Vladimír Čunát <vcunat <at> gmail.com>
To: 19775 <at> debbugs.gnu.org
Cc: Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#19775: Test failing after the CVE fix
Date: Thu, 05 Feb 2015 09:54:10 +0100

[Message part 1 (text/plain, inline)]

On 02/05/2015 01:56 AM, Paul Eggert wrote:
> XFAIL means it's eXpected to FAIL.  So when the test fails, that means
> the test is working (though 'grep' itself has a bug, of course).

I seem to be missing some basic understanding. The test is eXpected to 
fail, and it fails with assertion error, but "make check" fails (all 
other tests are passed or skipped).

Or is the assertion failure a wrong way to fail in the test?


Vladimir

[smime.p7s (application/pkcs7-signature, attachment)]

Message #14 received at 19775 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Vladimír Čunát <vcunat <at> gmail.com>, 
 19775 <at> debbugs.gnu.org
Subject: Re: bug#19775: Test failing after the CVE fix
Date: Thu, 05 Feb 2015 08:05:26 -0800

On 02/05/2015 12:54 AM, Vladimír Čunát wrote:
> The test is eXpected to fail, and it fails with assertion error, but 
> "make check" fails

Ah, you didn't show that part of the 'make' output.  'make check' should 
succeed, and does succeed on my platform (Fedora 21 x86-64). What 
platform are you running on?

Suppose you manually edit tests/Makefile, by removing the "@" from the 
triple-backref.log line, as follows.

--- Makefile~    2015-02-05 07:59:43.022516420 -0800
+++ Makefile    2015-02-05 07:59:51.559566420 -0800
@@ -2315,7 +2315,7 @@
     $(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS) 
$(LOG_DRIVER_FLAGS) -- $(LOG_COMPILE) \
     "$$tst" $(AM_TESTS_FD_REDIRECT)
 triple-backref.log: triple-backref
-    @p='triple-backref'; \
+    p='triple-backref'; \
     b='triple-backref'; \
     $(am__check_pre) $(LOG_DRIVER) --test-name "$$f" \
     --log-file $$b.log --trs-file $$b.trs \


What is the relevant part of the output of "make check" then? Here's 
what it looks like for me:

...
PASS: symlink
p='triple-backref'; \
b='triple-backref'; \
case $- in *e*) set +e;; esac; srcdirstrip=`echo "." | sed 's|.|.|g'`; 
case $p in ./*) f=`echo "$p" | sed "s|^$srcdirstrip/||"`;; *) f=$p;; 
esac; { mgn= red= grn= lgn= blu= brg= std=; am__color_tests=no; if test 
"X" = Xno; then am__color_tests=no; elif test "X" = Xalways; then 
am__color_tests=yes; elif test "X$TERM" != Xdumb && { test -t 1; } 
2>/dev/null; then am__color_tests=yes; fi; if test $am__color_tests = 
yes; then red=''; grn=''; lgn=''; blu=''; 
mgn=''; brg=''; std=''; fi; }; srcdir=.; export srcdir; 
case "triple-backref.log" in */*) am__odir=`echo "./triple-backref.log" 
| sed 's|/[^/]*$||'`;; *) am__odir=.;; esac; test "x$am__odir" = x"." || 
test -d "$am__odir" || /usr/bin/mkdir -p "$am__odir" || exit $?; if test 
-f "./$f"; then dir=./; elif test -f "$f"; then dir=; else dir="./"; fi; 
tst=$dir$f; log='triple-backref.log'; if test -n ''; then 
am__enable_hard_errors=no; else am__enable_hard_errors=yes; fi; case " 
triple-backref equiv-classes " in *[\ \    ]$f[\ \    ]* | *[\ \    
]$dir$f[\ \    ]*) am__expect_failure=yes;; *) am__expect_failure=no;; 
esac;  tmp__=$TMPDIR; test -d "$tmp__" || tmp__=.; TMPDIR=$tmp__; export 
TMPDIR; if test -n "$BASH_VERSION" || (eval "export v=x") 2>/dev/null; 
then export_with_values () { export "$@"; }; else export_with_values () 
{ sed_extract_var='s/=.*//'; 
sed_quote_value="s/'/'\\\\''/g;s/=\\(.*\\)/='\\1'/"; for arg in "$@"; do 
var=`echo "$arg" | sed "$sed_extract_var"`; arg=`echo "$arg" | sed 
"$sed_quote_value"`; eval "$arg"; export "$var"; done; }; fi; 
export_with_values VERSION='2.21.16-846e7-dirty' LOCALE_FR='fr_FR' 
LOCALE_FR_UTF8='fr_FR.UTF-8' AWK=gawk GREP_OPTIONS='' LC_ALL=C 
abs_top_builddir='/home/eggert/src/gnu/grep' 
abs_top_srcdir='/home/eggert/src/gnu/grep' 
abs_srcdir='/home/eggert/src/gnu/grep/tests' built_programs='grep egrep 
fgrep' srcdir='.' top_srcdir='..' CC='gcc -std=gnu99' 
GREP_TEST_NAME=`echo $tst|sed 's,^\./,,;s,/,-,g'` MAKE=make 
MALLOC_PERTURB_=1 PACKAGE_BUGREPORT='bug-grep <at> gnu.org' 
PACKAGE_VERSION=2.21.16-846e7-dirty PERL='perl' SHELL='/bin/sh' 
PATH='/home/eggert/src/gnu/grep/src:'"$PATH" ; 9>&2 /bin/sh 
../build-aux/test-driver --test-name "$f" \
--log-file $b.log --trs-file $b.trs \
--color-tests "$am__color_tests" --enable-hard-errors 
"$am__enable_hard_errors" --expect-failure "$am__expect_failure" -- 
/bin/sh   \
"$tst"
XFAIL: triple-backref
PASS: turkish-eyes
...

Message #17 received at 19775 <at> debbugs.gnu.org (full text, mbox):

From: Vladimír Čunát <vcunat <at> gmail.com>
To: 19775 <at> debbugs.gnu.org
Cc: Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#19775: Test failing after the CVE fix
Date: Thu, 05 Feb 2015 21:02:29 +0100

[Message part 1 (text/plain, inline)]

On 02/05/2015 05:05 PM, Paul Eggert wrote:
> Ah, you didn't show that part of the 'make' output.  'make check' should
> succeed, and does succeed on my platform (Fedora 21 x86-64). What
> platform are you running on?

It's 64-bit linux (NixOS.org). I did a few more trials, and the real 
problem isn't the CVE fix, but the (1) autoreconfiguration or (2) 
./bootstrap needed when applying that CVE patch or building from git, 
respectively (the patch also changes a Makefile.am).

Side note: now I see it will be probably best for nix(os) packaging to 
avoid either by just using 2.21 tarball and patching only the kwset.c 
file. That approach succeeds completely with:
# TOTAL: 138
# PASS:  119
# SKIP:  19
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

I hope the following will help to make the issue clearer.

It's perhaps that some dependencies are different than you expect (or 
missing). In the case of bootstrapping, e.g. maybe you expect a 
different gnulib version -- I didn't know which, so I chose the latest 
tag v0.1, etc. Builds on nix(os) are sandboxed, so only explicitly 
passed packages are visible to the builder, and no networking is 
allowed, etc.


Case (1): 2.21 tarball + patch + autoreconf. I'm sorry I didn't read the 
logs properly, but the tests *do* pass, only a few lines later there is 
what fails:

GEN      check_executable_TESTS
kwset-abuse
the above test scripts are not executable

Case (2): git on 2.21 or master + gnulib v0.1 + ./bootstrap.
There it's getting some segfaults and tells me:

# TOTAL: 86
# PASS:  49
# SKIP:  32
# XFAIL: 1
# FAIL:  4
# XPASS: 0
# ERROR: 0


Vladimir

[1-build.log (text/x-log, attachment)]

[2-build.log (text/x-log, attachment)]

[2-tests.log (text/x-log, attachment)]

[smime.p7s (application/pkcs7-signature, attachment)]

Message #20 received at 19775 <at> debbugs.gnu.org (full text, mbox):

From: Vladimír Čunát <vcunat <at> gmail.com>
To: 19775 <at> debbugs.gnu.org
Cc: Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#19775: Test failing after the CVE fix
Date: Thu, 05 Feb 2015 21:03:16 +0100

[Message part 1 (text/plain, inline)]

On 02/05/2015 05:05 PM, Paul Eggert wrote:
> Ah, you didn't show that part of the 'make' output.  'make check' should
> succeed, and does succeed on my platform (Fedora 21 x86-64). What
> platform are you running on?

It's 64-bit linux (NixOS.org). I did a few more trials, and the real 
problem isn't the CVE fix, but the (1) autoreconfiguration or (2) 
./bootstrap needed when applying that CVE patch or building from git, 
respectively (the patch also changes a Makefile.am).

Side note: now I see it will be probably best for nix(os) packaging to 
avoid either by just using 2.21 tarball and patching only the kwset.c 
file. That approach succeeds completely with:
# TOTAL: 138
# PASS:  119
# SKIP:  19
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

I hope the following will help to make the issue clearer.

It's perhaps that some dependencies are different than you expect (or 
missing). In the case of bootstrapping, e.g. maybe you expect a 
different gnulib version -- I didn't know which, so I chose the latest 
tag v0.1, etc. Builds on nix(os) are sandboxed, so only explicitly 
passed packages are visible to the builder, and no networking is 
allowed, etc.


Case (1): 2.21 tarball + patch + autoreconf. I'm sorry I didn't read the 
logs properly, but the tests *do* pass, only a few lines later there is 
what fails:

GEN      check_executable_TESTS
kwset-abuse
the above test scripts are not executable

Case (2): git on 2.21 or master + gnulib v0.1 + ./bootstrap.
There it's getting some segfaults and tells me:

# TOTAL: 86
# PASS:  49
# SKIP:  32
# XFAIL: 1
# FAIL:  4
# XPASS: 0
# ERROR: 0

Logs are attached.


Vladimir

[1-build.log (text/x-log, attachment)]

[2-build.log (text/x-log, attachment)]

[2-tests.log (text/x-log, attachment)]

[smime.p7s (application/pkcs7-signature, attachment)]

Message #25 received at 19775-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Vladimír Čunát <vcunat <at> gmail.com>
Cc: 19775-done <at> debbugs.gnu.org
Subject: Re: Test failing after the CVE fix
Date: Sat, 3 Sep 2016 00:26:28 -0700

http://bugs.gnu.org/19775

Evidently nobody has had time to look into this bug report. As the report is 
against a patch to an old release of grep, and the bug doesn't seem to have 
occurred in that release or in any later release, I'm boldly closing the bug as 
fixed.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.