Bug 105221

Summary:	grep(1): `grep -w -F ""` issue
Product:	Base System	Reporter:	martinko <gamato>
Component:	gnu	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed Overcome By Events
Severity:	Affects Only Me	CC:	emaste, kevans
Priority:	Normal
Version:	6.2-PRERELEASE
Hardware:	Any
OS:	Any

Description martinko 2006-11-06 20:00:41 UTC

after running the following command grep(1) starts eating all available cpu and won't finish:
$ echo qaz | grep -w -F ""

How-To-Repeat: just run the following from your shell:
echo qaz | grep -w -F ""

Comment 1 Rebecca Cran freebsd_committer

2008-01-27 20:58:22 UTC

It appears this bug was introduced with revision 1.20 of search.c.
It's still an issue on 7.0-RC1.

--
Bruce

Comment 2 dclark 2008-10-09 07:53:08 UTC

  gnu/105221

The behavior described in 105221 is due to 'grep' looping 
infinitely within Fexecute() of revision 1.25 of search.c. 

When used with the combination of '-w' and '-F' and 
the empty string, 'grep' enters a inescapable "while(1)" block 

A proposed fix then, is to immediately fail the search for a match 
when grep is called with this combination of options if the
string to match is zero-length (and thus, trivially does not match
the non-empty input!).

David K Lam
Engineer

Dorr H. Clark
Advisor

Graduate School of Engineering
Santa Clara University
Santa Clara, CA

http://www.cse.scu.edu/~dclark/coen_284_FreeBSD/105221.txt

--- /usr/src/gnu/usr.bin/grep/search.c	2006-02-19 04:27:39.000000000 +0000
+++ search.c	2008-08-21 00:29:38.000000000 +0000
@@ -959,6 +959,10 @@
 	}
       else if (match_words)
 	{
+
+          if(beg[len-1] == eol)
+            break;
+
 	  while (1)
 	    {
 	      int word_match = 0;

Comment 3 Kyle Evans freebsd_committer

2017-04-19 23:19:06 UTC

Some notes:

bsdgrep(1) is also affected in a different way by this old, old bug, so some notes:

gnugrep currently in base still exhibits the original behavior
bsdgrep will match the string
textproc/gnugrep will fail to match, presumably because it matches the 0-length BOL at the beginning of the string and the character immediately following it ("q") is a word character

Here's some other interesting behavior from textproc/gnugrep:

$ echo "" | fgrep -w ""

# Empty string, exit = 0, OK, that's..interesting
$ echo "qaz" | fgrep -w ""
# exit = 1, expected
$ echo " qaz" | fgrep -w ""
 qaz
$ printf "" | fgrep -w ""
# exit = 1, expected

On one hand, I don't agree with the idea that a 0-length match can *ever* produce a whole-word match- this seems misleading and probably not a practical use case.

On the other hand, this is technically correct behavior because the 0-length match is at the beginning of the string with a non-word-character on its other side.

Comment 4 Eitan Adler freebsd_committer

2018-05-20 23:53:33 UTC

For bugs matching the following conditions:
- Status == In Progress
- Assignee == "bugs@FreeBSD.org"
- Last Modified Year <= 2017

Do
- Set Status to "Open"

Comment 5 Ed Maste freebsd_committer

2021-08-06 22:58:28 UTC

No longer reproducible on head (w/ bsdgrep)

Comment 6 Ed Maste freebsd_committer

2023-05-01 13:46:43 UTC

Fixed by the switch to BSD grep in FreeBSD 13+. This is not fixed in 12.x but as there are no more releases to come it will unfortunately remain unfixed there.