Date: Fri, 12 Sep 1997 21:56:46 +0930 From: Mike Smith <mike@smith.net.au> To: Graham Wheeler <gram@cdsec.com> Cc: hackers@freebsd.org Subject: Re: Memory leak in getservbyXXX? Message-ID: <199709121226.WAA02951@word.smith.net.au> In-Reply-To: Your message of "Sat, 12 Sep 1997 14:16:53 %2B0200." <199709121216.OAA20310@cdsec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. > > Tell me about it 8-( > > It does seem like a memory leak, as the memory use reported by top grows > over time. I have memory allocation debugging code which confirms that > I have no leaks in my code (at least of C++ objects), and the fact that > older sites have been running for months seems to confirm this. OK. More to the point then it sounds like it's a memory leak due to some change in stdio. That's getting slightly easier to chase I guess. > > 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. > > I may have to do this, and give them a new kernel with kernel trace support > compiled in. But this is quite tricky - they're about 1000 miles away, and > don't have the skills to do a kernel update themselves, so it will be a last > resort. You wouldn't have to do anything more than supply them with a new executable; once you had the app in a the runaway state, get a core from it and bring it back. You would want to be interested in the state of the FILE buffer pool inside the stdio library (obviously you will need to keep your local symbols!) particularly. If you were going to be more adventurous, I would make a point of logging all calls to __smakebuf() in the stdio guts, and doing some tracking on the buffers it allocates; they're supposed to be freed in fclose(). This is going to mean a fairly chunky logfile, but if you help us run this one down we will be _very_ grateful! > Well, it could at least give a good indication if it is in fact the calls > to getservbyXXX that are the cause of the problem. I think you may have found a very subtle bug in the stdio library (unless you are poking it with a bad pointer). mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709121226.WAA02951>