Bug 105221 - grep(1): `grep -w -F ""` issue
Summary: grep(1): `grep -w -F ""` issue
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: gnu (show other bugs)
Version: 6.2-PRERELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-06 20:00 UTC by martinko
Modified: 2018-05-20 23:53 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 freebsd_triage 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"