MEMP_TCP_SEG: out of memory pool

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

MEMP_TCP_SEG: out of memory pool

Manuel Studer
Hi all

I've a an ftp server which builds up on the current LwIP TCP stack. When
doing heavy ftp operations the connection breaks and I get sooner or
later a "out of memory in pool 5" debug log output. Thereafter I can
still connect through my static listen port (21) but it fails then
always to allocate a new data connection providing me the same error
message mentioned as above.
According to the memp code the memmory pool 5 is reserved for TCP
segments. So it seems to me like the LwIp stack produces memory leaks in
the TCP segment handling.
What could be the reason for it? Have anyone of you a good hint how to
debug it efficiently?

Thanks
Manuel




_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: MEMP_TCP_SEG: out of memory pool

Kieran Mansley
On Thu, 2006-08-17 at 10:45 +0200, Manuel Studer wrote:

> Hi all
>
> I've a an ftp server which builds up on the current LwIP TCP stack. When
> doing heavy ftp operations the connection breaks and I get sooner or
> later a "out of memory in pool 5" debug log output. Thereafter I can
> still connect through my static listen port (21) but it fails then
> always to allocate a new data connection providing me the same error
> message mentioned as above.
> According to the memp code the memmory pool 5 is reserved for TCP
> segments. So it seems to me like the LwIp stack produces memory leaks in
> the TCP segment handling.
> What could be the reason for it? Have anyone of you a good hint how to
> debug it efficiently?

Another possibility is that it has just run out of memory for segments
not because they are being leaked, but because they are all being used
for the heavy network load.  You could get an idea of which of these it
is by increasing the number of TCP segments in the pool, and seeing if
the test fails in the same way:
 - if, as you increase the pool size, the test runs for a bit longer (at
the same load) that suggests a memory leak.
 - if, as you increase the pool size, the test fails at a higher network
load, that suggests it's just using them all for the traffic.

It won't rule out one or the other completely, but may give you an
idea.  

Another possibility is, when it fails to allocate a TCP segment, get it
to iterate over the pool and tell you what each of the TCP segments is
being used for (e.g. which list it is in, which connection, and so on).
This will probably need you to write some code though.

Hope that helps,

Kieran



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users