RTEMS4.10 _Heap_Block_allocate

Joel Sherrill joel.sherrill at OARcorp.com
Tue Aug 2 22:29:31 UTC 2011


On 08/02/2011 03:34 PM, Kate Feng wrote:
> Hello Sebastian,
>
> On 08/01/2011 02:04 AM, Sebastian Huber wrote:
>> Hello Kate,
>>
>> it may help to call _Heap_Walk() in the exception handler.
> Thanks for your suggestion. I might get some chances to run more
> tests and debug further in the coming September.
>
It may also help to turn on calling _Heap_Walk on every
malloc/free.  This sounds like it could also be a case of
overwriting the end of a buffer.
>>    Is there maybe a problem with sbrk()?
> It does not seem to be a problem with sbrk().  Besides, there
> is really no major code change in sbrk() between 4.9.4&  4.10.1/4.10.0.
>
>
> I did some tests last week, and thought it might be due to memory leak,
> which went undetected by the malloc_get_statistics().  The code calls
> malloc()
> and free() memory frequently, but it broke at one point in 4.10.1/4.10.0.
> It could be due to thread handler instead because it is a multi-threads
> application.  However, 4.10 ran smoothly with other multi-threads
> applications,
> which do not call malloc() and free() so frequently.
>
> The same application code ran smoothly in 4.9.4 and the
> need to extend beyond 32 M (e.g. sbrk() ) was not called at such an
> early stage of the application at run-time, as compared with that in
> RTEMS4.10.  This supports my suspicion of memory leak.  In fact, I also
> added code to force the application to extend beyond 32 M (e.g. sbrk() )
> early on at run-time in 4.9.4, it still ran smoothly.
>
> Kind Regards,
> Kate
>
>> Kind regards,
>>      Sebastian
>>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985





More information about the users mailing list