Xref: utzoo comp.unix.wizards:10564 comp.protocols.tcp-ip:4378
Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!elroy!jpl-devvax!lwall
From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Newsgroups: comp.unix.wizards,comp.protocols.tcp-ip
Subject: Re: mbuf leaks
Message-ID: <2690@jpl-devvax.JPL.NASA.GOV>
Date: 18 Aug 88 22:57:57 GMT
References: <2881@ttidca.TTI.COM>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA.
Lines: 15

In article <2881@ttidca.TTI.COM> mb@ttidca.tti.com (Michael Bloom) writes:
: Can anyone suggest good techniques for tracking down mbuf leaks?

I don't know if this is still valid, but in 4.2 I split up the DATA mbuf
type into twenty-some-odd different types of mbufs, depending on where they
were allocated.  After tweaking netstat to show which DATA type, it was easy
to see which allocator didn't have a matching deallocator.  Generally
that was sufficient to deduce the location of the leak.  Sometimes a
judicious printf or two helps as well, just so you don't go overboard.
Generally you want to hide a printf behind a debugging variable you can
turn on and off with adb.

There may be better tools to diagnose this by now...

Larry Wall
lwall@jpl-devvax.jpl.nasa.gov