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>
firstname.lastname@example.org (Larry Wall) writes:
> In article <2881@ttidca.TTI.COM> email@example.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.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:43:13 GMT