[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21513: closed (assertion error in pop_fail_stack)

From: GNU bug Tracking System
Subject: bug#21513: closed (assertion error in pop_fail_stack)
Date: Mon, 20 Jan 2020 17:51:01 +0000

Your message dated Mon, 20 Jan 2020 09:50:23 -0800
with message-id <address@hidden>
and subject line Re: bug#21513: (now an infinite loop in 
has caused the debbugs.gnu.org bug report #21513,
regarding assertion error in pop_fail_stack
to be marked as done.

(If you believe you have received this mail in error, please contact

21513: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21513
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: assertion error in pop_fail_stack Date: Fri, 18 Sep 2015 18:37:57 +0200

This command
grep -E '0|()0|\1|0'
will cause an assert error:
grep: regexec.c:1401: pop_fail_stack: Assertion `num >= 0' failed.

Happens both in the latest release (2.21) and the latest git code.

(this was found with american fuzzy lop)

Hanno Böck

mail/jabber: address@hidden

Attachment: pgpaidpofJtpy.pgp
Description: OpenPGP digital signature

--- End Message ---
--- Begin Message --- Subject: Re: bug#21513: (now an infinite loop in grep/tests/triple-backref?) Date: Mon, 20 Jan 2020 09:50:23 -0800 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
On 1/20/20 2:49 AM, Martin Liška wrote:

In this case an infinite loop is highly undesirable.

Sure, but the regex code is littered with highly undesirable code like this, as it's easy to use a weird regexp to make the code explode exponentially and there's little practical difference between that an infinite loop.

Come to think of it, the grep test infrastructure already has a way to deal with this sort of thing, so all we need to do to fix this particular glitch is adjust triple-backref to use timeout, which I did by installing the attached patch.

Thanks Andreas for diagnosing the problem. I hope there's a gcc bug report about it somewhere. I could not use Martin's recipe on Fedora 31 x86-64 because gcc -m32 -flto didn't look inside the .a files that the grep build procedure creates and uses. I've never had much luck with -flto anyway as it has a habit of running into compiler bugs. I now also see that Red Hat has qualms about the GOLD linker <https://fedoraproject.org/wiki/Changes/BINUTILS_GOLD> which the recipe relies on, as Google has decided not to continue GOLD development (which was news to me).

I'll mark Bug#21513 as done again, since the original report is fixed. The triple-backref bug is Bug#22793 and also glibc bug 11053, both of which are still open.

Attachment: 0001-tests-work-around-GCC-fprofile-generate-bug.patch
Description: Text Data

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]