Date: Fri, 13 Feb 2004 20:45:21 -0700 From: Robin Schoonover <end@endif.cjb.net> To: Steve Young <sdyoung@vt220.org> Cc: freebsd-current@freebsd.org Subject: Re: grep bug Message-ID: <20040214034523.B254E43D1F@mx1.FreeBSD.org> In-Reply-To: <AC98D3D2-5E98-11D8-A086-0003939C3B2E@vt220.org> References: <200402090704.i1974IVa032065@the-macgregors.org> <AC98D3D2-5E98-11D8-A086-0003939C3B2E@vt220.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 13 Feb 2004 19:51:23 -0700, Steve Young wrote: > > Arguably grep shouldn't eat up all your > memory when this happens but that's more of a GNU issue than a FreeBSD > issue, and really it would be kind of hard to handle > gracefully/portably. Have you reported this to the gnu bugs mailing > address? It may conceivably use 100% CPU but it shouldn't try and grab > 100% memory too. > grep has to pull in the entire line, and /dev/zero is a line with no end, so it tries pulling it all into memory until there is no more memory for a line to go into. (This part has been mentioned on this list before.) The reason is simple: regular expressions. You may have a regex that matches from beginning to end (^ to $), which means we need the entire line before we can determine if there is a match or not. plain grep (as far as I know) shouldn't require an entire line to operate on, just the length of the search. (There may be other reasons too) However, you rarely have lines long enough to make enough of a difference to cause problems. (1000 char lines? 1000000 char lines?) IMHO, it wouldn't be worth making the grep code more complex to handle such rare cases. -- Robin Schoonover (aka End) # "The POP3 server service depends on the SMTP server service, which # failed to start because of the following error: # The operation completed successfully." -- Windows NT Server v3.51
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040214034523.B254E43D1F>