Date: Fri, 12 Sep 1997 22:42:59 +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: <199709121313.XAA03137@word.smith.net.au> In-Reply-To: Your message of "Sat, 12 Sep 1997 14:51:53 %2B0200." <199709121251.OAA20346@cdsec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Hi again G'day 8) > > 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. It's quite possible that it's not actually making any syscalls at all, so ktrace isn't going to tell you much. Can you talk to the remote machine across the net? If you can login, you can of course attach a gdb to the running process and get all the data you need. > > 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. I am just pondering whether there is something particular about the behaviour that getservent() exhibits... still. > What about compiling with one of the malloc debug libraries that comes with > the FreeBSD distribution? Would that be able to shed any light? It's certainly worth trying. You can also try setting some options for the system malloc; I'd recommend 'AJ' (see malloc(3) for details on this.) > Perhaps I should also try compile the gateway with optimisation disabled; > mayhap it's the GNU compiler that's stuffing things up. What optimisation settings are you currently using? Do you custom-build your customers' systems, or are they vanilla installations? If it's something in the library that's broken, it'll be the build options for the system rather than your gateway that're at fault. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709121313.XAA03137>