Re: [lwip-users] TCP causing out of mem pool [RAW]

[Chris_S]

> Not sure what DAbort is, or what sort of things might trigger it, but

This is an ARM7 MCU.
There are 2 types of access violations: Data Abort & Prgm Abort.

> a pcap file is best

Ok, I'll send those next time.

>  In this trace we see 192.168.2.10 closing
> connections but 192.168.2.1 not doing likewise.

Yes exactly 192.168.2.1 is lwIP, 192.168.2.10 is the PC.
What would be causing lwIP not to Close ?
That sounds like it is either in lwIP or HTTPd, correct?

>  - lwIP out of PCBs: this is probably OK as it's expected and should
> recycle from the TIME_WAIT state.

That's problem #1.  They don't seem to come back.
It just keeps burning through them until all 31 are gone.
I gave my console output listing before.  They all get used up.
Isn't this the same issue as not Closing above?

>  - lwIP stops responding to new TCP connections: this is not OK
This is the same issue above I believe.


>  - lwIP crashes and goes to DAbort: this is not OK and needs more detail.

This is a pure CPU crash, going into the weeds.
I can see RAM being overwritten with garbage etc.
It seems to happen when I do browser refreshes very fast in a row.
Don't know if this is related to above or not.

> the network driver,  lwIP itself, and the application/OS.
> A bug in any one of these could be causing the problems you're seeing.

Burning through the PCBs the way it is, not freeing them or Closing, that
sure seems like it could only be in lwIP, or perhaps HTTPd.  Right now I am
trying HTTPd code that came from Luminary Micro.  It had CGI already setup I
was going to use later.  But I have a couple others too.  I think I will try
a different HTTPd and see what it acts like.  I did notice that one of the
other HTTPd has a number of notes in it about issues/bugs and I saw they
added some tcp_close() etc. in various areas.  It may be related.

lwIP is running in single thread.  I had problems before with the FreeRTOS
bothering my console UART section, which is in a different thread.
Originally I had 2K buffer for printf strs, but when I turn on all of the
LWIP debug it zoomed way up to 14K.  Tons of debug strs.  Had to add a
couple critical section blocks, but after that it now handles all 14K clean
and never causes any problems.  I've also checked the OS task stack sizes
and they peak at only 1/2 of the available space.

I'll try to get some more specifics.

Thanks,  Chris.