Re: mbuf leaks

Nick Felisiak (mcvax!!nick@uunet.UU.NET)
Fri, 19 Aug 88 14:06:36 WET DST

In article <2690@jpl-devvax.JPL.NASA.GOV> responding to <2881@ttidca.TTI.COM> (Larry Wall) writes:

> In article <2881@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.
> [...]
> There may be better tools to diagnose this by now...
> Larry Wall

Working with streams buffers (rather than 4.2 mbufs), on our TCP and X.25
packages, I have used the following technique sucessfully:

1. #define allocb(size, pri) Xallocb (size, pri, __LINE__, __FILE__),
    and ditto for all its friends (freeb, dupb, etc).

2. Add a couple of fields to the header structures, or build parallel
    structures maintained by the 'X*' functions, which record the line
    and file info thoughtfully included by cpp as the last two parameters.

3. When a lost buffer is identified, find out exactly where it came from.

Doing this *without* source is somewhat tricky - you need to put a small
module between the top of tcp (or whatever), and the stream head to catch
blocks coming up and down from the user. However, it is possible.

Nick Felisiak (

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:43:13 GMT