pc386 BSP memory management [was: Re: assert in malloc.c:383]

[Karel Gardas]

Thanks Sergey and Joel with this issue. Unfortunatelly it does not seem to
be so easy.

On Fri, 14 Jan 2005, Joel Sherrill <joel at OARcorp.com> wrote:

> > my question is: how to prevent it? Is assert on this place really needed,
> > especially when I consider that you set errno on this place. What does
> > this assert mean?
>
> This means you are freeing memory which was not allocated from
> the heap.  The address given to free MUST match that given to
> you by malloc.  So this could be a double free or a free of a bogus
> address.

OK, I've commented out one delete and everything started working well,
then I've un-commented this code again, recompile and everything is still
working well. Not only this is an issue, I've also hited it (this assert
in free) on different place in this code -- but just once from about 50
test starts of server/client so it looks quite strange, which leads me to
the question about RTEMS memory management on pc386 BSP. I'm most
interested in memory size limits/code size limits for this BSP, since in
powerpc/arm support I've seen some hard limits for RAM size in linkcmds
scripts which leads me to the care if the same also apply to i386/pc386
BSP platform, but I'm not able to "decode" pc386 linkcmds to find out if
it contains some limits or not. The reason for this ask is that compiled
MICO binary is quite big and also it might consume some memory and I
wouldn't like to hit some memory override issue with this. May I even
assume that RTEMS pick-up the RAM size from BIOS? i.e. if I play with
different Qemu setup for different memory sizes, will RTEMS use different
memory sizes too? I'm still talking only about pc386 BSP here.

Thanks a lot,
Karel
--
Karel Gardas                  kgardas at objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com