lwip-users
[Top][All Lists]
Advanced

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

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


From: Kieran Mansley
Subject: Re: [lwip-users] When the TCP_MSG have been exhausted, it could not be recovered.
Date: Tue, 20 Mar 2007 16:15:27 +0000

On Wed, 2007-03-21 at 00:01 +0800, geckook Xu wrote:

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

It's not sufficient to protect the stack with locks in just a few
places.  You have to ensure that there are *never* two threads active in
the lwIP stack at the same time.  You've managed to fix one case, but
there are many others as you have now seen.

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

Yes.

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

That sounds very strange, I'm not sure what's going wrong here.
However, I wouldn't be surprised if the leaks weren't also caused by the
problems you have with protecting the stack using locks.  Until you
solve that problem, everything else that goes wrong is likely to be
attributed to that.

Kieran





reply via email to

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