GNU bug report logs - #18425
test for new glibc regex bug

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 18425 in the body.
You can then email your comments to 18425 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: Jim Meyering <jim <at> meyering.net>
To: bug-grep <at> gnu.org
Subject: test for new glibc regex bug
Date: Mon, 8 Sep 2014 09:02:42 -0700

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

Paul found an ugly bug in glibc's regex.
Here's a test to trigger that from grep:

[0001-tests-add-expect-to-fail-test-for-a-glibc-regexp-bug.patch (application/octet-stream, attachment)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jim Meyering <jim <at> meyering.net>, 18425 <at> debbugs.gnu.org
Subject: Re: bug#18425: test for new glibc regex bug
Date: Mon, 08 Sep 2014 09:51:31 -0700

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

Thanks.  How about the attached simpler patch instead?  Since grep 
always uses glibc-compatible regex (and supplies its own substitute when 
the system lacks one), and since all known glibc-compatible 
implementations fail, it should be safe to assume that grep will fail on 
the new test.  We can worry about dealing with test successes later, 
when the bug gets fixed (and presumably grep's substitute regex 
implementation will get fixed too).

[0001-tests-add-expect-to-fail-test-for-a-glibc-regexp-bug.patch (text/x-patch, attachment)]

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

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 18425 <at> debbugs.gnu.org
Subject: Re: bug#18425: test for new glibc regex bug
Date: Wed, 10 Sep 2014 20:10:35 -0700

On Mon, Sep 8, 2014 at 9:51 AM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> Thanks.  How about the attached simpler patch instead?  Since grep always
> uses glibc-compatible regex (and supplies its own substitute when the system
> lacks one), and since all known glibc-compatible implementations fail, it
> should be safe to assume that grep will fail on the new test.  We can worry
> about dealing with test successes later, when the bug gets fixed (and
> presumably grep's substitute regex implementation will get fixed too).

Hi Paul,
Thanks for the review and suggestion.
But what about configure's --without-included-regex option?
With it, the test may well pass (counted as a failure, here) on
systems without glibc.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jim Meyering <jim <at> meyering.net>
Cc: 18425 <at> debbugs.gnu.org
Subject: Re: bug#18425: test for new glibc regex bug
Date: Wed, 10 Sep 2014 20:40:16 -0700

Jim Meyering wrote:
> what about configure's --without-included-regex option?
> With it, the test may well pass (counted as a failure, here) on
> systems without glibc.

Grep uses the glibc interface for regular expressions, and I expect that 
every current implementation of that interface has the bug, so this 
shouldn't be an issue now (though it would be an issue if the bug is 
ever fixed).

Or were you thinking of glibc 2.2.6 and earlier?  That might not have 
the bug, as it predates the circa-2002 regex rewrite that introduced the 
bug.  I suspect, though, that 2.2.6 regex would fail several other 
tests.  Are glibc versions this old still being used?

(Do users really complain when XFAIL tests succeed instead of failing as 
predicted?  Dumb question, I know; they'll complain about anything....)

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

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 18425 <18425 <at> debbugs.gnu.org>
Subject: Re: bug#18425: test for new glibc regex bug
Date: Thu, 11 Sep 2014 08:00:16 -0700

On Wed, Sep 10, 2014 at 8:40 PM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> Jim Meyering wrote:
>>
>> what about configure's --without-included-regex option?
>> With it, the test may well pass (counted as a failure, here) on
>> systems without glibc.
>
>
> Grep uses the glibc interface for regular expressions, and I expect that
> every current implementation of that interface has the bug, so this
> shouldn't be an issue now (though it would be an issue if the bug is ever
> fixed).
>
> Or were you thinking of glibc 2.2.6 and earlier?  That might not have the
> bug, as it predates the circa-2002 regex rewrite that introduced the bug.  I
> suspect, though, that 2.2.6 regex would fail several other tests.  Are glibc
> versions this old still being used?
>
> (Do users really complain when XFAIL tests succeed instead of failing as
> predicted?  Dumb question, I know; they'll complain about anything....)

That's it. When an XFAIL test passes, the framework counts
it as a failure and requests that a report including test-suite.log
be sent to the bug-reporting address. I have found that it is
almost always worthwhile to invest in avoiding those :-)

Previous Next

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