call to malloc causing an endless loop in _Heap_Allocate_aligned_with_boundary

[Sebastian Huber]

On 03/08/16 21:53, Philippe O'Reilly wrote:
>
> Hi,
>
> I am developing an application using RTEMS 4.10. My development 
> environment is a Windows PC, with MinGW installed on it. I compile 
> RTEMS and my application using gcc version 4.8.1. When I run my 
> application, the first printf() executed within a RTEMS task goes into 
> an infinite loop. The infinite loop is located in function 
> _Heap_Allocate_aligned_with_boundary.
>
> I isolated the problem by back tracing the code with GDB. Here is the 
> callback trace in GDB when I am stuck in an endless loop, with 
> information on variables *block* and *heap*:
>
> */(gdb) where/*
>
> */#0 _Heap_Allocate_aligned_with_boundary (heap=0x40393410, 
> alloc_size=128, alignment=0, boundary=0) at 
> c:/opt/rtems-4.10-mingw/src/rtems-4.10/cpukit/score/src/heapallocate.c:186/*
>
> */#1 0x40049684 in _Protected_heap_Allocate_aligned_with_boundary 
> (heap=0x40393410, size=128, alignment=0, boundary=0) at 
> c:/opt/rtems-4.10-mingw/src/rtems-4.10/cpukit/score/src/pheapallocate.c:37/*
>
> */#2 0x4003b254 in malloc (size=128) at 
> ../../cpukit/../../../leon3/lib/include/rtems/score/protectedheap.h:98/*
>
> */#3 0x40025a48 in __smakebuf_r (ptr=0x40d465d0, fp=0x40d46924) at 
> ../../../../../../../../gcc/newlib/libc/stdio/makebuf.c:95/*
>
> */#4 0x40023450 in __swsetup_r (ptr=0x40d465d0, fp=0x40d46924) at 
> ../../../../../../../../gcc/newlib/libc/stdio/wsetup.c:67/*
>
> */#5 0x4002552c in __sfvwrite_r (ptr=0x40d465d0, fp=0x40d46924, 
> uio=0x40d4638c) at 
> ../../../../../../../../gcc/newlib/libc/stdio/fvwrite.c:63/*
>
> */#6 0x4001b6a8 in _puts_r (ptr=0x40d465d0, s=0x400bd5b0 "RxTask") at 
> ../../../../../../../../gcc/newlib/libc/stdio/puts.c:94/*
>
> */#7 0x4001b6d8 in puts (s=0x400bd5b0 "RxTask") at 
> ../../../../../../../../gcc/newlib/libc/stdio/puts.c:103/*
>
> */#8 0x400133a4 in tblHandler_RxTask (unused=0) at 
> HighLevelControl/src/TableHandler.c:664/*
>
> */#9 0x400a496c in _Thread_Handler () at 
> c:/opt/rtems-4.10-mingw/src/rtems-4.10/cpukit/score/src/threadhandler.c:146/*
>
> */#10 0x400a486c in _Thread_Handler () at 
> c:/opt/rtems-4.10-mingw/src/rtems-4.10/cpukit/score/src/threadhandler.c:88/*//
>
> */(gdb) print  *block/*
>
> */$11 = {prev_size = 0, size_and_flag = 0, next = 0x0, prev = 0x0}/*
>
> */(gdb) print  heap/*
>
> */$12 = (Heap_Control *) 0x40393410/*
>
> There seems to be a problem with the pointer to the heap, since the 
> content of the first block of the heap is all zeros.
>
> Does anyone came across the same problem and have a solution for it?
>

You have probably a heap corruption, e.g. use after free or out of 
bounds write access. In case you always end up with the same corrupt 
heap block, then you can set a write break point, e.g.

watch ((Heap_Block *) addr)->prev_size)

In RTEMS 4.11 and 4.12 a simple heap protection is enabled via 
RTEMS_DEBUG which helps to find common heap corruption problems.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.