FreeBSD 4.9 losing mbufs!!!

[Stephen Clark]

Robert Watson wrote:

>On Tue, 18 Apr 2006, Stephen Clark wrote:
>
>  
>
>>I have discovered that if I disable quaqqa/ospfd then I don't lose mbufs! 
>>This makes it appear that the mbuf leak is in the multicast routing logic. 
>>In fact I lose mbufs even with the both system basically idle but with a 100 
>>vpn/gre with multicast going on thru the gre then the vpn.
>>
>>Any ideas on where to focus my continued investigation?
>>
>>Thanks to everybody who has responded.
>>    
>>
>
>Steve,
>
>Sorry not to have caught this thread earlier; I've been on travel for the last 
>few weeks.  My general suggestion would be to try to narrow the code paths 
>traversed to try to eliminate as much code as possible from the search.  It 
>sounds like you've done that pretty effectively :-).
>
>Typically, memory leaks occur in edge error cases, where the memory is not 
>properly released, or ownership is unclear.  My suggestion would be to add 
>counters (or look at existing counters where already present) and see if 
>there's an error case being triggered in about the same quantity that mbuf 
>leakage is occuring.  Chances are, there's an error being returned and a 
>missing m_freem().
>
>Based on your comments above, I might also pay attention to the routing socket 
>path -- the rate of leak could correspond to the routing daemons talking to 
>the network stack, rather than the rate of traffic.  For example, it could be 
>that one of the routing messages is handled improperly resulting in a leak.
>
>Unfortunately, tracking down memory leaks can be quite difficult, and tends to 
>require a combination of dogged persistence and luck...
>
>Robert N M Watson
>
>  
>
Robert,

Thanks for your response. I am in the process of moving our app to 6. 
stable to see if the problem still exists. If it does then maybe I can't 
generate some enthusiasm form the FreeBSD
community to take moew of an interest in the problem. I have a lot of C 
experience but not with the *BSD network stack, still trying to get a 
good understanding of the flow of the packets thru the stack.

Our next release will be based on 6 but that is months away. We have 
some Athon 64 X2 we are putting in that will handling 100 to 200 vpn/gre 
tunnels and right now ipintrq slowly grows
which eventually forces a reboot of the systems. Fortune 2000 companies 
don't like see that happen.

Regards,
Steve

-- 

"They that give up essential liberty to obtain temporary safety, 
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty 
decreases."  (Thomas Jefferson)