Bug 27506 - memory leak in libfetch
Summary: memory leak in libfetch
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: Dag-Erling Smørgrav
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-05-21 17:30 UTC by thierry
Modified: 2001-05-27 14:11 UTC (History)
0 users

See Also:


Attachments
file.diff (299 bytes, patch)
2001-05-21 17:30 UTC, thierry
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description thierry 2001-05-21 17:30:01 UTC
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.

Fix: the following patch seems to cure the memory leak :
-----------------------------------------
How-To-Repeat: just having a constantly running program fetching repeated files
using libfetch (the fetch(1) program is a bad example, as it runs for
a very short period of time - my program runs for extended periods of
time, like one week, and fetches many files each second)
Comment 1 Peter Pentchev freebsd_committer freebsd_triage 2001-05-21 17:33:23 UTC
Responsible Changed
From-To: freebsd-bugs->des

Over to the libfetch author/maintainer.
Comment 2 des 2001-05-21 18:59:39 UTC
Try this patch instead of the one in the PR:

Index: ftp.c
===================================================================
RCS file: /home/ncvs/src/lib/libfetch/ftp.c,v
retrieving revision 1.63
diff -u -r1.63 ftp.c
--- ftp.c       2001/04/24 00:06:20     1.63
+++ ftp.c       2001/05/21 17:58:31
@@ -418,13 +418,10 @@
     io->dir = -1;
     io->dsd = -1;
     DEBUG(fprintf(stderr, "Waiting for final status\n"));
-    if ((r = _ftp_chkerr(io->csd)) != FTP_TRANSFER_COMPLETE)
-       io->err = r;
-    else
-       io->err = 0;
+    r = _ftp_chkerr(io->csd);
     close(io->csd);
-    io->csd = -1;
-    return io->err ? -1 : 0;
+    free(io);
+    return (r == FTP_TRANSFER_COMPLETE) ? 0 : -1;
 }

 static FILE *

DES
-- 
Dag-Erling Smorgrav - des@ofug.org
Comment 3 Dag-Erling Smørgrav freebsd_committer freebsd_triage 2001-05-27 14:10:30 UTC
State Changed
From-To: open->feedback
Comment 4 Dag-Erling Smørgrav freebsd_committer freebsd_triage 2001-05-27 14:10:47 UTC
State Changed
From-To: feedback->closed

Fixed in -CURRENT and -STABLE.