Summary: console spam from "named".

From: Thomas Leavitt (leavitt@webcom.com)
Date: Wed Jun 28 1995 - 18:29:38 CDT


Summary of responses: rt_malloc: memdebug overflow.

a) Apply patch #102479-01 SunOS 5.4: memory leak/mismanagement
in in.named

 Note: patch is not publicly available via SunSolve FTP site,
  unless it is bundled in with the other recommended patches.

 b) nuke lousy Sun named that isn't capable of handling heavy loads,
    and replace with "bind 4.9.3" available at: ftp.vix.com

 c) restart named on a regular basis

 Also included: new FAQ entry and debug report.

We are choosing to get a Sun support contract.

Thomas

     Thanks to:

     Kalpesh Dharia <kalpeshd@daffy.netrex.com>
     Karim Saouli saouli@math.ethz.ch
     Santithorn Bunchua <keh@au.ac.th>
     Don Lenamond don@alaska.opensys.COM
     Scott Kamin <Scott.Kamin@Central.Sun.COM>
     Brad Burdick bburdick@radio.com
     Richard <richard.perlotto@tempe.vlsi.com>

     This from jamie (jamie@mail.multiverse.com):
     I recommend getting the entire 2.4 patch setup. Get
     ftp://sunsolve1.Sun.COM/pub/patches/2.4_Recommended.tar.Z

     Ric Anderson <ric@rtd.com>
     Geoff White <geoffw@nexsys.net>
     Andy McCammont mccammaa@expt05.stp.xfi.bp.com
      Andreas Stoll <astoll@Hypo.DE>
      Casper Dik <casper@Holland.Sun.COM>
      Karl Mumford <uucp@esoc.esa.de>

      For the curious, here is the detailed story... I was
      quite surprised myself that Sun could release a piece
      of software with such an glaringly obvious bug.

      Message 22/89 from Pell Emanuelsson Jun 20 '95 at 11:59 am
      Return-Path: <pell@lysator.liu.se>
      Subject: Re: Console spam from "named".
> sunstation named[7424]: rt_malloc: memdebug overflow
> sunstation last message repeated xxxx times.
      This is a well known bug, which we've been hit by as well. As far as I
      know, it hasn't yet been fixed, although there is a named patch for Sol-2
      (102479). Fortunately the bug doesn't seem to influence the basic
      functionality of named.
      Here's the bug report, which you can refer to if you talk to Sun:
      ===
       Bug Id: 1178808
Category: network
 Subcategory: dns
  Release summary: s494_fcs, sol2.4_hw11_94, sol2.4_x86drv4, s494_fcs_e
   Synopsis: memory leak/mismanagement in in.named
   Integrated in releases:
    Patch id:
     Description:
     [lip 10/3/94]
     The most noticeable symptom of this problem is a continuous series
     of error messages in /var/adm/messages of the form:
     ...
     Oct 3 16:18:43 calypso-2.oit.unc.edu named[116]: rt_malloc: memdebug overflow
     Oct 3 16:18:43 calypso-2.oit.unc.edu named[116]: rt_malloc: memdebug overflow
     Oct 3 16:18:44 calypso-2.oit.unc.edu last message repeated 3 times
     Oct 3 16:18:44 calypso-2.oit.unc.edu last message repeated 3 times
     Oct 3 16:18:48 calypso-2.oit.unc.edu named[116]: rt_malloc: memdebug overflow
     Oct 3 16:18:48 calypso-2.oit.unc.edu named[116]: rt_malloc: memdebug overflow
     Oct 3 16:18:48 calypso-2.oit.unc.edu named[116]: rt_malloc: memdebug overflow
     Oct 3 16:18:48 calypso-2.oit.unc.edu named[116]: rt_malloc: memdebug overflow
     Oct 3 16:18:52 calypso-2.oit.unc.edu named[116]: rt_malloc: memdebug overflow
     Oct 3 16:18:52 calypso-2.oit.unc.edu named[116]: rt_malloc: memdebug overflow
     ...
     Another symptom is that the in.named process image continually grows over
     time.
     After looking at some of the in.named code, I noticed several problems with
     how memory is allocated/freed.
     1. calloc() is defined locally for the purposes of maintaining a cache
of requests, yet the corresponding rt_free() routine is never called!
   memory allocated through calloc() might be freed through the library
      version of free() or not freed at all.
      2. The C library version of malloc() is used in several places as well.
 This is inconsistent use of memory allocation and freeing routines.
    in.named probably takes memory faults at other sites or will eventually
       core dump at this site.
       3. The memory cache used in storage.c is silly even if it were used
  correctly.

  I think the solution is to consistently use the library versions of
  malloc(), free(), etc... and scrap everything in storage.c . Also, the
  code needs to be carefully analyzed to make sure that everything malloced
  is eventually freed if it is no longer needed.

  SunSite UNC is a very visible site (one of the few East Coast Mosaic/ftp
  hubs) and thisbug should be fixed ASAP and a patch for on494 supplied.
  This site has been a major embarassment for Sun on the internet. This
  is probably a serious problem on any major internet hub.
   History:
   Submitter: lip Date: 10/03/94
   Dispatch Operator: bugtraq Date: 10/03/94
   Evaluator: wpm Date: 10/25/94
   ===
   Cheers - Pell
   --
   Lysator Computer Society | email: pell@lysator.liu.se
   Linkoping University | WWW home at: http://www.lysator.liu.se/~pell/
   Sweden | or: http://www.cs.tu-berlin.de/~pell/

   The FAQ maintainer cheated and added this to the FAQ:

   +5.36) Why do I get ``named[]: rt_malloc: memdebug overflow'' errors?

       That's caused by a bug in the Solaris 2.4 named. You need to install
   patch (sparc):
   102479-01: SunOS 5.4: memory leak/mismanagement in in.named

       There is no equivalent patch for x86.

   --- end of excerpt from the FAQ

   Questions marked with a * or + have been changed or added since
   the FAQ was last posted

   The most recently posted version of the FAQ is available from
   ftp.fwi.uva.nl in directory /pub/solaris

--
Web Communications (sm)            Thomas Leavitt--leavitt@webcom.com
Voice: (408) 457-9671 x101         Lead Systems & Network Admin./Tech Suppt.
 
Web Communications Home Page <URL:http://www.webcom.com/>



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:28 CDT