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

[Leon Woestenberg]

Hello Marc,

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

But studying this code, isn't q _always_ NULL once the if
condition is evaluated?

Too bad I do not understand what this piece of code is
supposed to do as there are no comments :-)

Leon.

> 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.
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/lwip-users
>