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