>Number:         17911
>Category:       bin
>Synopsis:       less(1) version 374 (NetBSD 1.6Beta4) defaults infininite buffer space
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Aug 11 13:14:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Michael L. Riechers
>Release:        1.6Beta4
>Organization:
M L Riechers Systems Engineering
>Environment:
NetBSD t982.rse.com 1.6_BETA4 NetBSD 1.6_BETA4 (EASTERN-1.6Beta4.backside) #0: Tue Jul 23 23:27:54 EDT 2002     mlr@t982.rse.com:/usr/local/NetBSD/NetBSD-release-1-6beta4/src/sys/arch/macppc/compile/EASTERN-1.6Beta4.backside macppc
>Description:
If the -b command line option is not provided on invocation of less, then
maxbufs remains as it was declared, in ch.c:
static int maxbufs = -1;
fch_get() then assumes that he's allowed an infinite number of file
buffers, and does so.  This is a problem less'ing large files (say 40M
or larger) because uvm and less have a contest to see which of them
squander the most memory: less will probably use around 70M of data
space to buffer the file, while uvm will FILE the whole 40M of duplicate
data.  The general result of this is to push every other process to
swap, until swap is exhausted.

This is not less's expected behavior.  From less man page:
"By  default  64K  of  buffer space is used for each file...".
>How-To-Repeat:
less a big file (>20M).  Run top.  Watch both the less process and uvm
File get Really Big.

less same big file using less -b64 <the_big_fil>.  less remains sane,
uvm File gets Really Big (but uvm will handle that ok).
>Fix:
Quick fix: always use -b64 on the command line, or alias less="less -b64".

In ch.c, set
static int maxbufs = -1;
to
static int maxbufs = 8;
or fix the ./opttbl.c:371:init_option() function to call opt_b to
properly initialize maxbufs (as was (AFAICT) its original intent)
>Release-Note:
>Audit-Trail:
>Unformatted: