Re: [ECOS] eth_recv out of MBUFs

[John Mills <johnmills at speakeasy dot net>]

Cyl -

You may be running out of free memory to allocate and the enternet 
buffer is just the place where it shows up.

Short answer:
You may need to look for a memory leak somewhere in your code. These are 
no fun to find.

Long answer: eCos sets up a pool of available memory for allocation when 
it starts up. This pool is broken into blocks (the 'mbuf's in question, I 
think) and when a service or application allocates memory, eCos first 
checks whether any space is available in the one or more mbufs already 
assigned to that level of your code. If space is available then storage is 
allocated from that source for your data object; if not, the memory 
manager attempts to get another mbuf to work with. If none is available, 
you are "out of MBUFs".

This block-allocation is a common approach in RTOS as it protects memory 
allocation and helps keep overhead code under control.

Diagnosis: If you have generous read-write memory available, increase the 
amount which is broken up into mbufs at eCos startup. (Sorry - I can't 
point you to the correct code at the moment.) If this solves the problem, 
you had some kind of worst-case collision. If this makes the problem less 
frequent that may still be the issue. It this only delays the problem I 
would bet on a memory leak (unbalanced 'malloc' and 'free' usage in some 
thread). These are no fun to find.

Suggestions:
 1. Inactivate different threads and see if this solves the problem, then 
go looking for memory leakage in the thread(s) that were running when the 
problem occurred. Recently added code is the prime suspect, of course.

 2. Write macros to "wrap" the system's 'malloc' and 'free' code so that 
they print from whence they are called and for what objects they are 
allocating. Then replace all calls to the system 'malloc' and 'free' with 
calls to your macros. (This approach makes it easy to turn the debug code 
on and off by at one spot by changing the macros' definitions: through a 
compilation switch for example.)

 3. Use static rather than dynamic ('malloc') storage allocation wherever 
this is practical (not a bad idea in embedded real-time applications that 
may need to run stably for indefinite periods.)

 4. Use a free ('valgrind') or commercial code analyzer to track memory 
allocation (another "learning opportunity"!).

DISCLAIMERS:
 1. I don't have eCos code handy so I may be misunderstanding the problem 
completely. Sorry.

 2. I'm using eCos-2.0 so the issue may be quite different in 3.x.

 3. If I missed the boat here, I hope folks will correct me and we will 
both learn from it.

 - John Mills

On Fri, 16 Jul 2010, cyl cyl wrote:

> Hello!
> I got warning: eth_recv out of MBUFs, when I was writing to a
> connection(frequently) which is NOT  NORMALLY closed (hardware is
> taken out). Usually "write" returns -1,  but sometimes it shows that
> message. I'm using ecos3.0 by the way.
> Anything will be helpful !
> Thank you!

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss