Date: Wed, 12 Jan 2005 16:25:27 GMT From: Jeffrey Katcher <jmkatcher@yahoo.com> To: freebsd-gnats-submit@FreeBSD.org Subject: misc/76153: Significant memory leak in libfetch (fix enclosed) Message-ID: <200501121625.j0CGPR7A003994@www.freebsd.org> Resent-Message-ID: <200501121630.j0CGUSXE067727@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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@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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200501121625.j0CGPR7A003994>