From nobody@FreeBSD.org  Tue Jun 12 05:28:40 2001
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 4909337B405
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 12 Jun 2001 05:28:40 -0700 (PDT)
	(envelope-from nobody@FreeBSD.org)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.3/8.11.3) id f5CCSe678796;
	Tue, 12 Jun 2001 05:28:40 -0700 (PDT)
	(envelope-from nobody)
Message-Id: <200106121228.f5CCSe678796@freefall.freebsd.org>
Date: Tue, 12 Jun 2001 05:28:40 -0700 (PDT)
From: conrad@th.physik.uni-bonn.de
To: freebsd-gnats-submit@FreeBSD.org
Subject: mbus leakage in FreeBSD 4.3R somewhere
X-Send-Pr-Version: www-1.0

>Number:         28098
>Category:       i386
>Synopsis:       mbus leakage in FreeBSD 4.3R somewhere
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jun 12 05:30:01 PDT 2001
>Closed-Date:    Mon Dec 3 09:40:54 PST 2001
>Last-Modified:  Mon Dec 03 09:41:17 PST 2001
>Originator:     Jan Conrad
>Release:        FreeBSD 4.3R
>Organization:
Univ. Bonn, Germany
>Environment:
FreeBSD wigner.th.physik.uni-bonn.de 4.3-RELEASE FreeBSD 4.3-RELEASE #1: Thu May 24 18:01:27 CEST 2001     conrad@merlin.th.physik.uni-bonn.de:/freebsd/misc/src/sys/compile/MERLIN  i386
>Description:
There seems to be a mbuf leakage which can be triggered by userland programs (i.e.: gtk-gnutella run by our young folk :-) in 4.3R.

The mbufs remain allocated AFTER THE PROGRAM TERMINATES!

After the program was running one gets outputs like the following:
[159]# netstat -m
1397/4224/6144 mbufs in use (current/peak/max):
        1337 mbufs allocated to data
        60 mbufs allocated to packet headers
69/806/1536 mbuf clusters in use (current/peak/max)
2668 Kbytes allocated to network (57% of mb_map in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines

Normal operation looks like (we run a FreeBSD cluster and our machines are very stable otherwise...)
[20]# netstat -m
80/624/6144 mbufs in use (current/peak/max):
        77 mbufs allocated to data
        3 mbufs allocated to packet headers
64/184/1536 mbuf clusters in use (current/peak/max)
524 Kbytes allocated to network (11% of mb_map in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines

If one lets run the program for a longer time, the following error
message is generated:

Jun 12 11:54:20 wigner /kernel: looutput: mbuf allocation failed

Letting it run even further, the system panics with a page fault
and dumps core. However the core dump gives no reference to mbufs
whatsoever (dumps etc. are available). Du to the broken '-M' of netstat I can give no mbuf output from the core...

In addition, even if the system did not yet panic and the program is terminated (with the above err msg occuring several times) the box may panic after a while. This case I observed once, and the mbuf usage had gone back to something like 3000/6144/6144 before the crash


>How-To-Repeat:
run gtk-gnutella for a while
>Fix:
unknown
>Release-Note:
>Audit-Trail:

From: Ian Dowse <iedowse@maths.tcd.ie>
To: freebsd-gnats-submit@FreeBSD.org
Cc: conrad@th.physik.uni-bonn.de
Subject: Re: i386/28098: mbus leakage in FreeBSD 4.3R somewhere 
Date: Mon, 18 Jun 2001 20:27:28 +0100

 In message <200106121228.f5CCSe678796@freefall.freebsd.org>, conrad@th.physik.u
 ni-bonn.de writes:
 >>Description:
 >There seems to be a mbuf leakage which can be triggered by userland programs (
 >i.e.: gtk-gnutella run by our young folk :-) in 4.3R.
 >
 >The mbufs remain allocated AFTER THE PROGRAM TERMINATES!
 
 Further diagnostic information provided by Jan suggests that this
 is not an mbuf leak. The gtk-gnutella program seems to be very
 demanding on mbuf resources; the server process had 100-200 tcp
 sockets open, and on many socket transmit queue there were chains
 of 20-30 mbufs containig data (it must be doing lots of small
 writes).
 
 The mbufs are eventually slowly reclaimed, but I think those on
 the send queues can remain there for some time if the remote client
 stops responding or stops reading from the connection.
 
 I'll leave the PR open for now until the details are confirmed.
 There is also the issue of the page-faults when mbufs run out,
 but that is probably covered by another PR.
 
 Ian
State-Changed-From-To: open->feedback 
State-Changed-By: iedowse 
State-Changed-When: Sun Dec 2 16:31:10 PST 2001 
State-Changed-Why:  

Can this be closed? I think we determined that there was no mbuf 
leak, but that the application was just tying up a lot of mbuf 
resources in many send queues. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=28098 
State-Changed-From-To: feedback->closed 
State-Changed-By: iedowse 
State-Changed-When: Mon Dec 3 09:40:54 PST 2001 
State-Changed-Why:  

Submitter says that this can be closed. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=28098 
>Unformatted:
