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

[geckook Xu]

> 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.

I think the CLOSED state is changed after I call tcp_close(pcb), so I
add lock at the front and back of tcp_close(), then the assertion
about CLOSED didn't appear frequently, but assertion about TIME_WAIT
will appear at function tcp_tcp_slowtmr. What is the metter?


> > 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

Yes, TCP_MSG structures somehow being leaked so that they never become
available for reuse.
Do you mean I can referer to
http://lists.gnu.org/archive/html/lwip-devel/2007-03/msg00242.html ?

I still found another problem about TCP_MSG structures and
MEMP_NUM_TCP_SEG structures.
in the cc.h file, when I include a new header file,MEMP_NUM_TCP_SEG
structures would be leaked and TCP_MSG structures not, but when I
remove this header file, the TCP_MSG structures whuld be leaked
instead.