Re: [lwip-users] Found bug in pbuf.c

[Marc Boucher]

Hi David,

isn't a pbuf_free(p) missing after the pbuf_chain(q, p)
in src/netif/slipif.c:slipif_input() ?

Marc

diff -x CVS -ur cvs-20030604/lwip/src/netif/slipif.c dist/src/netif/slipif.c
--- cvs-20030604/lwip/src/netif/slipif.c        2003-05-12 08:18:15.000000000 
-0400
+++ dist/src/netif/slipif.c     2003-06-06 04:29:45.000000000 -0400
@@ -150,6 +150,7 @@
        
        if (q != NULL) {
          pbuf_chain(q, p);
+         pbuf_free(p);
        } else {
          q = p;
        }

On Wed, May 28, 2003 at 01:23:21PM -0400, David Haas wrote:
> We spent a lot of time debugging pbuf memory leak issues and I actually
> thing we do have it right now. While there certainly could be some bugs,
> I have pounded on basic tcp connections and have run continuous data
> across the connections for several days without any memory leaks. I am
> really very confident that there are no basic memory leaks in the pbuf code.
> 
> The general idea is that pbuf->ref should be incremented for each
> reference made to a pbuf. That reference could be a pointer that tcp or
> an application holds or it could be from another pbuf in a chain. The
> operation you describe where a pbuf is chained should result in the
> second pbuf having a ref count of 2 and the first one having a ref count
> of 1. If the application  who calls pbuf_chain() does not need to keep a
> pointer to the second pbuf, then it may now safely free it (the second
> pbuf). That is what happens in the tcp_enqueue() code you are describing.
> 
> My version of tcp_out.c looks like this around line 211:
> 
>      ++queuelen;
> 
>      /* Chain the headers and data pbufs together. */
>      pbuf_chain(seg->p, p);
>      pbuf_free(p);
> 
> If your version looks different, then I don't think you are using the
> latest lwip.
> 
> Are you saying that there is a memory leak only from code inspection or
> are you really finding a problem in operation?
> 
> David.