From owner-freebsd-hackers Mon May 21 6:59:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from aifhs8.alcatel.fr (aifhs8.alcatel.fr [212.208.74.153]) by hub.freebsd.org (Postfix) with ESMTP id 2AB2137B422; Mon, 21 May 2001 06:59:29 -0700 (PDT) (envelope-from Thierry.Herbelot@alcatel.fr) Received: from frmta003.netfr.alcatel.fr (frmta003.netfr.alcatel.fr [155.132.251.32]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with SMTP id PAA20501; Mon, 21 May 2001 15:59:40 +0200 (MET DST) Received: by frmta003.netfr.alcatel.fr(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C1256A53.004CE463 ; Mon, 21 May 2001 15:59:52 +0200 X-Lotus-FromDomain: ALCATEL From: Thierry.Herbelot@alcatel.fr To: hackers@freebsd.org, Audit@freebsd.org Message-ID: Date: Mon, 21 May 2001 15:59:15 +0200 Subject: memory leak in libfetch ? (with patch) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG hello, [this is using a 4.3-Release machine] I'm using libfetch for automated file transfers from a program (via ftp). The program is running for long periods of time, and seems to be leaking memory (at least it's SIZE in top(1) just grows and grows - the swap is also increasingly used). As there is no dynamically allocated memory in my program, one suspect could be libfetch(3). Indeed, there are 5 calls to malloc(3) in the source code of the lib : - in common.c, line 263, which should not cause a leak as the pointer is stored in buf, which is later saved, - in common.c, line 362, in a function which is not used in my app (the file name is known) - in fetch.c, line 377, in a function which is used only for http/https transfers, thus not in my app, - in http.c, line 517, in a function which is used only for http/https transfers, thus not in my app, - finally in ftp.c, line 434, in a suspicious manner : the "io" variable is located on the stack, thus visible only from this function, gets a pointer to a newly allocated ftpio struct and disappears after _ftp_setup() returns. The comparison between usr.bin/compress/zopen.c:zclose() and lib/libfetch/ftp.c:_ftp_close() shows a missing free(cookie) at the end of the function. the following patch seems to cure the memory leak : ----------------------------------------- --- ftp.c.ori Sat Apr 7 19:30:48 2001 +++ ftp.c Mon May 21 15:26:42 2001 @@ -422,7 +422,9 @@ io->err = 0; close(io->csd); io->csd = -1; - return io->err ? -1 : 0; + r = io->err ? -1 : 0; + free(io); + return (r); } static FILE * ----------------------------------------- TfH To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message