mb@ttidca.TTI.COM (Michael Bloom) (07/09/88)
Can anyone suggest good techniques for tracking down mbuf leaks? This is for a port I've done of the 4.3-tahoe tcp to a sys5r3 box. I believe the problem to be somewhere in the ethernet driver, as the leakage did not appear until after adding it. (Previous testing via the loopback device did not reveal any problems.)
mb@ttidca.TTI.COM (Michael Bloom) (07/09/88)
A couple of hours ago, in article <2881@ttidca.TTI.COM> I wrote:
> Can anyone suggest good techniques for tracking down mbuf leaks?
The problem was simple: turned out to be an "m_free" where there
should have been an "m_freem". While unneeded at present, i'd still be
interested in learning of other peoples network debugging techniques.
A new question: Has anyone tried rewriting the mbuf allocation
routines and macros to internally use streams data structures? This
looks like it might be a workable approach to converting the BSD TCP
to streams, without having to change too much of the rest of the code.
If I can find out soon enough whether or not s5r4 tcp will be streams
based, I may end up doing such a conversion to get a head start prior
to r4 availability. I know I've asked this before, but I've gotten no
replies: does anyone know if this will be the case?mja@TWG.COM (Mike Anello) (07/14/88)
I don't know anyone who has rewritten mbuf allocation to use streams data structures, but I do know that you need to do a lot more work to convert BSD TCP to streams than you realize. The mbuf stuff is simple compared to creating true STREAMS drivers or modules that conform to the STREAMS architecture. Your approach may be a start but I believe that you have a long way to go. You should get a copy of the AT&T Streams Programmer Guide. This will surely show you how the rest of the work beyond mbuf conversion is very extensive. Mike Anello The Wollongong Group
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (08/19/88)
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