Re: [lwip-users] When the TCP_MSG have been exhausted, it could not be recovered.

[Kieran Mansley]

On Tue, 2007-03-20 at 18:09 +0800, geckook Xu wrote:
> When the tcp_pcb have been exhausted,will meet the problem listed below.
> Assertion "tcp_input: active pcb->state != CLOSED" at line 170 in tcp_in.c
> below code is locate in tcp_in.c lines 602
> pcb->state = CLOSED;
> 
> There are the only reason which make assert "tcp_input: active
> pcb->state != CLOSED".
> 
> Why assert here? or what's reason will lead to the assertion?

There are a number of lists of PCBs internal to lwIP.  One of them - the
"tcp_active_pcbs" should not have in it any PCBs that are in CLOSED,
TIMEWAIT, or LISTEN.  When in those states the PCB should be in a
different list (e.g. tcp_tw_pcbs or tcp_listen_pcbs).  This assertion is
therefore making sure that there are no CLOSED PCBs in the active list. 

As to how this happened, from looking at the code there is a short gap
between a PCB being marked closed (tcp_process()) and it being removed
from the active list (in tcp_input()).  In tcp_process() the TF_CLOSED
flag is set, and this is then noticed in tcp_input() and the PCB removed
from the list.  If, in between these two happening, your timer function
ran, it would find the lists in an inconsistent state.  However, there
is supposed to be only one thread active in the stack at once.  We could
change the code so that the pcb was removed from the list before its
state was changed to CLOSED, thus ensuring it remained consistent at all
times, and this would be a good thing, but it would still leave you with
potential problems if I'm right and you have your timer thread running
at the same time as another thread is active in the lwIP code. 

> There are still anothe problem when the tcp_pcb have been exhausted:
> I set TCP_MSG to 255, and when the tcp_pcb are exhausted, it will be
> exhausted too.
> once TCP_MSG have been exhausted,then TCP_MSG values would not be recovered.
> What should I do now?

I'm not sure I understand your problem?  Are you just running out of
TCP_MSG structures?  Or are they somehow being leaked so that they never
become available for reuse?  Could this be related to BUG#19345 which
Frederic Bernon is working on?

Kieran