misc/76153: Significant memory leak in libfetch (fix enclosed)

[Jeffrey Katcher]

>Number:         76153
>Category:       misc
>Synopsis:       Significant memory leak in libfetch (fix enclosed)
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jan 12 16:30:28 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     Jeffrey Katcher
>Release:        5.3-STABLE
>Organization:
>Environment:
FreeBSD mammon.comcast.net 5.3-STABLE FreeBSD 5.3-STABLE #4: Fri Jan  7 14:02:42 PST 2005     katcher at mammon.comcast.net:/usr/src/sys/i386/compile/MAMMON  i386

>Description:
I was debugging a program with a libfetch back end under valgrind and found that libfetch was leaking about 1K/connection.  My program uses a lot of individual connections so growth was noticable during a long run.
>How-To-Repeat:
Run any libfetch linked binary under valgrind
>Fix:
It's an easy fix:
Conn is the connection structure, and though every conn is freed, the fact that conn has a malloced field is ignored.  The fix is simply to check for the existence of this field and freeing it immediately before freeing conn itself.  

Patch follows:
*** common.c.orig       Tue Jan 11 18:44:03 2005
--- common.c    Tue Jan 11 18:44:14 2005
***************
*** 605,610 ****
--- 605,615 ----
        if (--conn->ref > 0)
                return (0);
        ret = close(conn->sd);
+ 
+       if (conn->bufsize) {
+               free(conn->buf);
+       }
+ 
        free(conn);
        return (ret);
  }

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