bug#21513: (now an infinite loop in grep/tests/triple-backref?)

[Martin Liška]

On 1/18/20 11:16 PM, Paul Eggert wrote:
> 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

Hello.

I'm attaching build log that leads to the failure.

> 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.

In this case an infinite loop is highly undesirable. That can justify why the 
assert
should be transformed into abort. Note that we don't want -DDEBUG for a release
package build of grep.

Thanks,
Martin

stuck_log.txt.bz2
Description: application/bzip