>Number:         8681
>Category:       bin
>Synopsis:       grep may bomb out with "memory exhausted"
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Oct 25 07:50:59 1999
>Last-Modified:
>Originator:     Havard Eidnes
>Organization:
	RUNIT AS
>Release:        NetBSD 1.4 release branch as of a few days ago
>Environment:
NetBSD vever.runit.sintef.no 1.4.1 NetBSD 1.4.1 (VEVER) #5: Wed Oct 20 19:42:00 MEST 1999     he@vever.runit.sintef.no:/usr/src/sys/arch/i386/compile/VEVER i386

>Description:
	It appears that grep/egrep/fgrep use mmap() to read files but
never releases the memory segments with munmap(), causing an ever
increasing data segment (?) / virtual size, eventually bumping into
resource limits.


>How-To-Repeat:
	In my /sys/arch/i386/compile tree I have a couple of 30+MB
netbsd.gdb files lying around.  Then, doing:

cd /sys/arch/i386/
find . -type f | xargs grep -n constab /dev/null
grep: memory exhausted
grep: memory exhausted

	From following grep's progress with 'top', it appears that it
gets an ever increasing virtual size.  Inspection of the source code
would seem to indicate that it is mmap()ing the files to be searched,
and never doing munmap() on the same regions when they have been
searched, thus causing an ever increasing virtual size until they bump
into the resource limit set for datasize (in my case 128MB, identical
to physical memory on this box).

(I thought that mmap()ed segments weren't counted against resource
limits, but apparently they are... (now?))


>Fix:
Two alternatives:
 o Turn off HAVE_MMAP in /usr/src/gnu/usr.bin/grep/config.h
 o Find a better solution (doesn't immediately look obvious)
>Audit-Trail:
>Unformatted: