Date: Fri, 12 Sep 1997 20:25:08 +0930 From: Mike Smith <mike@smith.net.au> To: Graham Wheeler <gram@cdsec.com> Cc: mike@smith.net.au (Mike Smith), freebsd-bugs@freebsd.org, hackers@freebsd.org Subject: Re: Memory leak in getservbyXXX? Message-ID: <199709121055.UAA02692@word.smith.net.au> In-Reply-To: Your message of "Sat, 12 Sep 1997 10:19:29 %2B0200." <199709120819.KAA19990@cdsec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > That's fairly odd; malloc()/free() do not call fstat(). Are you using > > the system malloc() or the GNU version? > > The system malloc, as far as I know. And I did search the source for fstat, > and didn't find it, so I agree this is odd. But that's what gdb is reporting > in the stack backtrace... Just out of curiosity, seeing as it appears to be inside malloc inside the stdio library, a couple of other questions; do you use the funopen() functionality at all? > > Not as far as I am aware; something like this would have been somewhat > > of a showstopper I would expect. If you have a copy of the CVS > > repository on hand extracting the changes between 2.1 and 2.2 would be > > very straightforward. I just went over this; there's been very little at all changed there, most of the differences are the addition of YP support. Each of these stuffups is actually deep inside the stdio library; I suspect that this is just about all your application actually does with stdio? btw. you might want to call setservent(1) before making lookups to avoid the open/close overhead you're incurring with every getserv* call you're currently making. Looking more, do you fiddle with the _bf._base or _nbuf fields in any FILE structures? Particularly after you've closed the file? > process for nearly a year without a restart or reboot). So if the problem > is a memory leak, for example, it may not show up except in situations like > ours where there are so many calls. If it's a memory leak then it sounds like it's inside the stdio library, possibly in fopen()/fclose(). Without more data it's going to be hard to track this one. If you have a forgiving customer, it would be immensely useful to build a copy of libc with debugging symbols and link your binary static, and then have the user run that until it dies. What happens if you install the 2.1 compatability kit and run the 2.1 version of the application? > I'm considering prescanning the tables used once at the start and looking > up all the services once only; this is a good idea from a performance point > of view and may make the problem go away. If you can spare the memory, that's far and away the best approach. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709121055.UAA02692>