Date: Fri, 13 Feb 2004 19:51:23 -0700 From: Steve Young <sdyoung@vt220.org> To: Rob MacGregor <freebsd.macgregor@blueyonder.co.uk> Cc: freebsd-current@freebsd.org Subject: Re: grep bug Message-ID: <AC98D3D2-5E98-11D8-A086-0003939C3B2E@vt220.org> In-Reply-To: <200402090704.i1974IVa032065@the-macgregors.org> References: <200402090704.i1974IVa032065@the-macgregors.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 9, 2004, at 12:04 AM, Rob MacGregor wrote: > I can confirm this behaviour under 5.2-CURRENT from the 5th of > February: > > -bash-2.05b$ grep -r foo / >/dev/null > grep: /dev/network: Permission denied > grep: /dev/geom.ctl: Permission denied > grep: /dev/devctl: Permission denied > grep: /dev/ata: Permission denied > grep in realloc(): error: allocation failed > Abort trap (core dumped) > Feb 9 06:59:59 phoenix kernel: pid 55974 (grep), uid 1001: exited on > signal > 6 ( > core dumped) Hi Rob, The problem here is that grep is trying to grep /dev/zero and is trying to allocate all your memory in the process of handling this infinite input. This will happen when grep is used on any of the /dev files that spit out unlimited output, such as /dev/random and the sound input device, I suspect. 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. Thanks, Steve.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AC98D3D2-5E98-11D8-A086-0003939C3B2E>