GNU bug report logs - #21513
assertion error in pop_fail_stack

Previous Next

Package: grep;

Reported by: Hanno Böck <hanno <at> hboeck.de>

Date: Fri, 18 Sep 2015 16:38:02 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Martin Liška <mliska <at> suse.cz>
Cc: Andreas Schwab <schwab <at> suse.de>, 21513 <at> debbugs.gnu.org
Subject: bug#21513: (now an infinite loop in grep/tests/triple-backref?)
Date: Sat, 18 Jan 2020 14:16:45 -0800

On 1/18/20 6:44 AM, Martin Liška wrote:
> I can confirm that it never finishes on i586.

I can't reproduce the problem, either on Ubuntu 18.04.3 x86-64 (GCC Ubuntu 
7.4.0-1ubuntu1~18.04.1) or on Fedora 31 (GCC 9.2.1 20190827 x86-64 (Red Hat 
9.2.1-1)). I did what should have been the equivalent of:

git clone https://git.savannah.gnu.org/git/grep.git
# This is commit 23bf27015e0cc45d0012f54b8e24ac19fdca89f7.
cd grep
./bootstrap
./configure --with-included-regex CC='gcc -m32'
make
make check

and it worked for me; the triple-backref test had an XFAIL and did not loop. Can 
you send me more-detailed instructions for how to reproduce the bug?

> I would recommend to replace   DEBUG_ASSERT (num >= 0);
> which expands to:
>    ((num >= 0) ? (void) 0 : __builtin_unreachable ());
> 
> into:
> 
>    if (num < 0)
>      __builtin_abort ();

The regexec.c code doesn't abort, I guess under the theory that one is supposed 
to fix the code than insert runtime assertions that slow things down. You can 
compile with -DDEBUG if you want it to abort, but be prepared for other grep 
tests to fail if you do so. Admittedly this is a messy area.
This bug report was last modified 5 years and 175 days ago.

Previous Next

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