Bind 8.1.2 in.named memory leak in Solaris 7

[William P. Malloy]

This is a known bug in Solaris 7 (in the resolver NOT in /usr/sbin/in.named)
4211042 Bind 8.1.2 in.named memory leak in Solaris 7

The fix is to install patch 106938-02 (for SPARC) or 106939-02 (for x86).
The fact that the "fix" is in libresolv and NOT in in.named should
point out the problem in just ripping out code and replacing it with
something else.  Nothing may get fixed and there is always the possibility
of hiding (instead of solving) the underlying problem.

This is also why you should keep up on the patches/updates.  Check out
the http://access1.sun.com/ web site for patch reports on your running OS.

=wpm	William P. Malloy

DISCLAIMER I am not speaking officially for Sun, just stating an opinion.

In article <03256804.00681CAE.00 at notesbsb03.bancobrasil.com.br>,
 <jgomide at bancobrasil.com.br> wrote:
>Hi Jim
>
>When I start named, it takes 4M. After 3 hours it is eating 16 M of memory.
>About the bind version, bind 8.1.2 in Solaris 7 (message subject). I believe
>this version *has* a memory leak.
>I'm sure I have to upgrade to bind 8.2, but where do I get it compiled for
>Solaris 7?
>
>Joaquim Gomide
>
>Jim Reid <jim at mpn.cp.philips.com> on 08/10/99 12:04:38
>
>To:   F5028449 Joaquim E M Gomide/BANCO DO BRASIL at bancobrasil.com.br
>cc:   bind-users at isc.org
>
>Subject:  Re: Bind 8.1.2 in.named memory leak in Solaris 7
>
>    Joaquim> I´m having the  problem describe in the article. Look at
>    Joaquim> top´s information below:
>    Joaquim>  PID USERNAME THR PRI NICE  SIZE   RES STATE   TIME    CPU COMMAND
>    Joaquim> 28729 root       1  58    0  545M  417M sleep  33:57  2.78%
>in.named
>    Joaquim> 29065 root       1  58    0 2120K 1504K cpu     0:00  0.51% top
>
>Wow! A name server of that size is unusual. You might expect something
>to be that big at a major ISP, but not for the environment you
>describe.
>
>    Joaquim> The server is just 3 day up and it is only a name server.
>    Joaquim> This is a internal dns server and is used for zone
>    Joaquim> transfer, so the cache should not grow as big
>    Joaquim> as it is. We don't have so many internal hosts to cache.
>
>Hmm. There are a few things you could check. The first is the name
>server's config file and zone files. Are you *sure* these are really
>as small as you say they are? How big is named after it has been
>started and it has only loaded your zone files? The second thing to do
>would be to make the name server dump its cache - assuming you have
>enough free disk space for it somewhere. That would let you find out
>what was in the cache: maybe there's some idiot application that's
>flooding the name server with queries, perhaps doing an exhaustive
>search of the name space. ie
>     for (i = a; i <= zzzzzzzzzzzzzzzzzzzzzzzzzzz; i++)
>          lookup (i.com);
>
>A third possibility could be you're running really ancient name server
>code that has a memory leak. [You didn't say which version of BIND you
>were running.] Try running 8.2.1. It's always a good idea to run up to
>date name server code because it should have fewer problems with
>memory leaks (memory that doesn't get freed whenever it is no longer
>needed). It'll also have the known security holes plugged.
>
>
>
>
>
>