Re: mbuf leaks


Nick Felisiak (mcvax!tarantula.spider.co.uk!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>
lwall@jpl-devvax.jpl.nasa.gov (Larry Wall) writes:

>
> 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.
> [...]
>
> There may be better tools to diagnose this by now...
>
> Larry Wall
> lwall@jpl-devvax.jpl.nasa.gov
>

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

nick@spider.co.uk (nick%spider.co.uk@uunet.uu.net)



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