user/5008: small memleak in usr.bin/grep/util.c

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

user/5008: small memleak in usr.bin/grep/util.c

Benjamin Pineau
>Number:         5008
>Category:       user
>Synopsis:       small memleak in usr.bin/grep/util.c
>Confidential:   yes
>Severity:       non-critical
>Priority:       low
>Responsible:    bugs
>State:          open
>Quarter:        
>Keywords:      
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 07 14:30:01 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     ben
>Release:        grep version 0.9
>Organization:
net
>Environment:
       
        System      : OpenBSD 3.8
        Architecture: OpenBSD.i386
        Machine     : i386
>Description:

In usr.bin/grep/util.c, the procfile() function calls
grep_open() or grep_fdopen(), that both allocate mem and put
a file_t stuct on it and return a pointer to it (or free
it and return NULL).

The problem is that procfile() grep_close() this pointer but
forgets to free() it (as the name imply, grep_close() only
*close* the file descriptor stored on the file_t struct).

The fix is trivial.

>How-To-Repeat:

Feed grep with many files and watch the memory consumption growing.

>Fix:

Index: util.c
===================================================================
RCS file: /cvs/src/usr.bin/grep/util.c,v
retrieving revision 1.30
diff -u -r1.30 util.c
--- util.c 3 Apr 2005 19:12:40 -0000 1.30
+++ util.c 7 Feb 2006 14:00:47 -0000
@@ -112,6 +112,7 @@
  nottext = grep_bin_file(f);
  if (nottext && binbehave == BIN_FILE_SKIP) {
  grep_close(f);
+ free(f);
  return 0;
  }
 
@@ -142,6 +143,7 @@
  if (Bflag > 0)
  clearqueue();
  grep_close(f);
+ free(f);
 
  if (cflag) {
  if (!hflag)

>Release-Note:
>Audit-Trail:
>Unformatted:

Reply | Threaded
Open this post in threaded view
|

Re: user/5008: small memleak in usr.bin/grep/util.c

Otto Moerbeek
The following reply was made to PR user/5008; it has been noted by GNATS.

From: Otto Moerbeek <[hidden email]>
To: Benjamin Pineau <[hidden email]>
Cc: [hidden email]
Subject: Re: user/5008: small memleak in usr.bin/grep/util.c
Date: Tue, 7 Feb 2006 15:49:21 +0100 (CET)

 On Tue, 7 Feb 2006, Benjamin Pineau wrote:
 
 > >Number:         5008
 > >Category:       user
 > >Synopsis:       small memleak in usr.bin/grep/util.c
 
 To improve cosmic balance, I prefer this...
 
  -Otto
 
 
 Index: file.c
 ===================================================================
 RCS file: /cvs/src/usr.bin/grep/file.c,v
 retrieving revision 1.7
 diff -u -p -r1.7 file.c
 --- file.c 7 Feb 2005 08:47:18 -0000 1.7
 +++ file.c 7 Feb 2006 14:48:51 -0000
 @@ -228,4 +228,5 @@ grep_close(file_t *f)
  /* can't happen */
  errx(2, "invalid file type");
  }
 + free(f);
  }

Reply | Threaded
Open this post in threaded view
|

Re: user/5008: small memleak in usr.bin/grep/util.c

Benjamin Pineau
In reply to this post by Benjamin Pineau
The following reply was made to PR user/5008; it has been noted by GNATS.

From: Benjamin Pineau <[hidden email]>
To: Otto Moerbeek <[hidden email]>
Cc: [hidden email]
Subject: Re: user/5008: small memleak in usr.bin/grep/util.c
Date: Tue, 7 Feb 2006 17:37:21 +0100

 On Tue, Feb 07, 2006 at 03:49:21PM +0100, Otto Moerbeek wrote:
 > ===================================================================
 > RCS file: /cvs/src/usr.bin/grep/file.c,v
 > retrieving revision 1.7
 > diff -u -p -r1.7 file.c
 > --- file.c 7 Feb 2005 08:47:18 -0000 1.7
 > +++ file.c 7 Feb 2006 14:48:51 -0000
 > @@ -228,4 +228,5 @@ grep_close(file_t *f)
 >   /* can't happen */
 >   errx(2, "invalid file type");
 >   }
 > + free(f);
 >  }
 
 Ok, this fix the bug here
 (and cosmos remains balanced).