Re: memory leak in net_receive

To: lettieri@iet.unipi.it (Giuseppe Lettieri)
Subject: Re: memory leak in net_receive
From: Godmar Back <gback@cs.utah.edu>
Date: Fri, 24 Mar 2000 15:22:29 -0700 (MST)
Cc: oskit-users@fast.cs.utah.edu (oskit users)
In-Reply-To: <000a01bf9576$aa32aab0$fc097283@iet.unipi.it> from "Giuseppe Lettieri" at Mar 24, 2000 10:52:26 AM
Sender: owner-oskit-users@fast.cs.utah.edu


 Hi Guiseppe,

I agree with your evaluation.  My fault.

I've checked in the following patch that moves the addref() after the
IEEE rejection code, which should hopefully work:

Index: net_receive.c
===================================================================
RCS file: /usr/lsrc/mach/CVS/oskit/freebsd/net/net_receive.c,v
retrieving revision 1.23
diff -u -r1.23 net_receive.c
--- net_receive.c       1999/11/09 23:38:25     1.23
+++ net_receive.c       2000/03/24 22:19:34
@@ -111,9 +111,6 @@
        if (!ifp)
                return 0;
 
-       /* keep a reference around! */
-       oskit_bufio_addref(b);
-
        /* map data in */
        /* buf, dest, offset, count */
        err = oskit_bufio_map(b, (void **)&frame, 0, pkt_size);
@@ -138,6 +135,9 @@
 #endif
        }
 
+       /* keep a reference around! */
+       oskit_bufio_addref(b);
+
        /* NOW we're getting BSDish... */
 
        /* save cpl */
@@ -171,9 +171,8 @@
         m->m_len = payload;
 
        /*
-        * fill in another story here...
+        * mark this mbuf as referring to an oskit bufio 
         */
-
        m->m_ext.ext_bufio = b;
        m->m_flags |= M_EXT;
 


"Fill in another story"?  What was I smoking?

	- Godmar

> 
> This is a multi-part message in MIME format.
> 
> ------=_NextPart_000_0007_01BF957F.0AAD0680
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> We have noticed that, when networking code is running, available memory =
> (managed by malloc_lmm) monotonically decreases. Looking at code in =
> freebsd/net/net_receive.c (OSKit version 990722), we have found that the =
> problem is caused by IEEE 802.3 frames. These frames are discarded. =
> However,  the corresponding sk_buff (encapsulated in a bufio object) is =
> addref()erenced, but not release()d.
> We do not have version 20000202 runnig. However, looking at the code, we =
> think that the bug has not been removed.
> =20
> 
> ------=_NextPart_000_0007_01BF957F.0AAD0680

References:

memory leak in net_receive

From: "Giuseppe Lettieri" <lettieri@iet.unipi.it>