Date: Fri, 12 Sep 1997 14:51:53 +0200 (SAT) From: Graham Wheeler <gram@cdsec.com> To: mike@smith.net.au (Mike Smith) Cc: freebsd-bugs@freebsd.org, hackers@freebsd.org Subject: Re: Memory leak in getservbyXXX? Message-ID: <199709121251.OAA20346@cdsec.com> In-Reply-To: <199709121226.WAA02951@word.smith.net.au> from "Mike Smith" at Sep 12, 97 09:56:46 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Hi again > > 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. The ktrace idea was suggested by someone else - when the app `freezes', the suggested running ktrace at that point to see where it it actually spinning. > 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, I should be able to do this here - if it is indeed a memory leak, then it should be possible to track it down without going so far as having the app freeze up. What about compiling with one of the malloc debug libraries that comes with the FreeBSD distribution? Would that be able to shed any light? > > 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). Which is also possible. Perhaps I should also try compile the gateway with optimisation disabled; mayhap it's the GNU compiler that's stuffing things up. -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709121251.OAA20346>