lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [lwip-users] Releasing pcb after tcp_new()


From: Bill Auerbach
Subject: RE: [lwip-users] Releasing pcb after tcp_new()
Date: Mon, 14 Jan 2008 15:54:30 -0500

Simon,

 

Does it make sense to include a listen_pcb pointer in tcp_pcb that tcp_bind fills in (otherwise it’s NULL).  On the final close of the pcb, if tcp_listen isn’t NULL, memp_free it as well.  In spite of you asking if it’s valid to bind to an open pcb, this resolves the leak because tcp_listen is grabbing a new tcp.

 

Bill Auerbach

 


From: address@hidden [mailto:address@hidden On Behalf Of Goldschmidt Simon
Sent: Monday, January 14, 2008 10:02 AM
To: Rick Culver; Mailing list for lwIP users
Subject: RE: [lwip-users] Releasing pcb after tcp_new()

 

I have filed a bug report about the tcp_bind() question, so that it doesn't get lost:

http://savannah.nongnu.org/bugs/?22020

 

Simon

 

 


Von: address@hidden [mailto:address@hidden Im Auftrag von Rick Culver
Gesendet: Montag, 14. Januar 2008 15:28
An: Mailing list for lwIP users
Betreff: Re: [lwip-users] Releasing pcb after tcp_new()

Bill,

Thanks for the response.  After some more investigation I discovered that you are correct, it appears the pcb does get released by the stack but not immediately after the tcp_close() function.  I can wait until the state == CLOSED but I would think that by then the pcb would have already been released by the stack and my pointer to the pcb could be pointing to erroneous memory.  Not sure about that.  Anyway, thanks for the help and hopefully someone else will pick up on this tread and provide some more input.

Rick

 

----- Original Message -----

Sent: Wednesday, January 09, 2008 12:17 PM

Subject: RE: [lwip-users] Releasing pcb after tcp_new()

 

Rick,

 

We’re going down the same path, more or less.  One thing to watch on tcp_close is the tcb_pcb isn’t actually finished being used until later – one of the tcp timers is completing the connection.  This ties up pcbs internally for older connections until they are closed.  Allocate MEMP_NUM_TCP_PCB to twice what you think – or more if you are opening and closing connections a lot.

 

One thing I would like to see is a callback when the pcb is going to be deallocated so that dynamic memory associated with it can be released when the data is sent and the connection completes later.  Maybe someone knows already how to do this?

 

Thanks,

 

Bill Auerbach

 


From: address@hidden [mailto:address@hidden On Behalf Of Rick Culver
Sent: Wednesday, January 09, 2008 12:29 PM
To: address@hidden
Subject: [lwip-users] Releasing pcb after tcp_new()

 

I am using CALLBACK API and set up a pcb using tcp_new() followed by tcp_bind() followed by tcp_listen() & tcp_accept().  In my accept() for a valid connection I use tcp_close() to close the LISTEN connection to avoid any additional connection requests for a new connection.  When I am done using the connection I use tcp_close() to shut it down and then repeat the process with tcp_new() to start a new LISTEN port.  My problem is 2 fold.

 

First I find that the 2nd time through the tcp_bind() function I get an ERR_USE return which appears to be caused by the active list of pcb still having the old port number in it.  I think ther is a problem with tcp_bind() which causes this to happen.

 

Secondly (and the biggest problem) is that once I get the ERR_USE then I have a pcb allocated and this consumes pcb space and I eventually run out of space.  So the question is, if I get an error with tcp_bind() how can I release the pcb allocated by the tcp_new() so I do not consume pcb memory space and fill it up.  I think there could be a problem with tcp_bind() giving this error which is also an issue.  Can anyone suggest how to approach these problems?

Rick

 

 


_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users


reply via email to

[Prev in Thread] Current Thread [Next in Thread]