[ECOS] malloc

[ECOS] malloc

[Lewin A.R.W. Edwards]

Quick question: Does anyone here (using 1.3.1) have problems using malloc?

I'm using the Cirrus 7212 and malloc seems to be very random in behavior - 
sometimes it will succeed on a few allocations and then fail on one more. 
Then, it will succeed on some (larger!) allocations in the same session.

I'm asking this because I want to know if I have some deeper underlying 
problem; broken heap management is not a killer for me because I prefer to 
avoid dynamic allocation in embedded apps.
=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."

Re: [ECOS] malloc

[Jonathan Larmour]

"Lewin A.R.W. Edwards" wrote:
> 
> Quick question: Does anyone here (using 1.3.1) have problems using malloc?
> 
> I'm using the Cirrus 7212 and malloc seems to be very random in behavior -
> sometimes it will succeed on a few allocations and then fail on one more.
> Then, it will succeed on some (larger!) allocations in the same session.

I found some problems in the memory allocator a while back and fixed them.
Alas I also redesigned the memory allocation system at the same time, so it
wouldn't be easy to backport the patches, although you could maybe try -
the new version is in anonymous CVS under services/memalloc/common

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] malloc

[Lewin A.R.W. Edwards]

Hi Jonathan,

> > I'm using the Cirrus 7212 and malloc seems to be very random in behavior -
>
>I found some problems in the memory allocator a while back and fixed them.
>Alas I also redesigned the memory allocation system at the same time, so it

I'm happy to hear that there _is_ a known problem with the version I've 
got, because it indicates that I probably don't have some deeper lurking 
problem :)

I have written my own "dirty memory manager" which sounds rather like how 
you described the old eCos manager, except that my implementation does not 
support realloc or free. It has a fixed heap size (static array).

When I am using dynamic allocation, I don't want the structures to have any 
permanent lifespan. There are only two parts of my code that use dynamic 
allocation, because they need to create an indeterminate (known only at 
runtime) number of structures of an indeterminate size. I know roughly what 
the aggregate size of these structures will be, but not how the space will 
be distributed. The structures exist while I am decoding a particular data 
stream, and have no meaning thereafter, so my memory manager essentially 
only works with one process - you call a "reset" function before you use 
it, and then allocate all you want. When you're finished, there is no need 
to deallocate anything because the next time the reset function is called, 
all sins are forgiven.

It is much, much, much easier for me to do this than to have to worry about 
heap fragmentation.

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."