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