Infinite loop on _Heap_Allocate

LOPEZ CUEVA Patricia patricia.lopezcueva at
Thu Aug 24 13:22:43 UTC 2017

Hi Jiri,

Thanks for your quick reply. Indeed, I did not know that patches had to be applied to qemu, I thought it was only to the toolset.

I have downloaded the three patches and tried to directly apply them to qemu-2.9.0 without success. The patches are intended for which version of qemu?

In the end, I managed to apply them by modifying them a bit (only very minor modifications), but it does not compile. Note that qemu-2.9.0 compiles without any problem without the patches.

I will not include the whole compilation output because it is huge and it would not be useful. I will include only the first few lines of the compilation errors:

  CC      sparc-softmmu/hw/sparc/grlib_ambapnp.o
In file included from /usr/local/tools/qemu-2.9.0/include/exec/cpu-common.h:7:0,
                 from /usr/local/tools/qemu-2.9.0/include/hw/hw.h:9,
                 from /usr/local/tools/qemu-2.9.0/include/hw/qdev.h:4,
                 from /usr/local/tools/qemu-2.9.0/include/hw/sysbus.h:6,
                 from /usr/local/tools/qemu-2.9.0/hw/sparc/grlib_ambapnp.c:23:
/usr/local/tools/qemu-2.9.0/include/exec/hwaddr.h:11:1: error: unknown type name 'uint64_t'
typedef uint64_t hwaddr;
In file included from /usr/local/tools/qemu-2.9.0/include/qemu/bswap.h:4:0,
                 from /usr/local/tools/qemu-2.9.0/include/exec/cpu-common.h:10,
                 from /usr/local/tools/qemu-2.9.0/include/hw/hw.h:9,
                 from /usr/local/tools/qemu-2.9.0/include/hw/qdev.h:4,
                 from /usr/local/tools/qemu-2.9.0/include/hw/sysbus.h:6,
                 from /usr/local/tools/qemu-2.9.0/hw/sparc/grlib_ambapnp.c:23:
/usr/local/tools/qemu-2.9.0/include/fpu/softfloat.h:94:1: error: unknown type name 'uint8_t'
typedef uint8_t flag;
/usr/local/tools/qemu-2.9.0/include/fpu/softfloat.h:137:1: error: unknown type name 'uint16_t'
typedef uint16_t float16;
/usr/local/tools/qemu-2.9.0/include/fpu/softfloat.h:138:1: error: unknown type name 'uint32_t'
typedef uint32_t float32;
/usr/local/tools/qemu-2.9.0/include/fpu/softfloat.h:139:1: error: unknown type name 'uint64_t'
typedef uint64_t float64;
/usr/local/tools/qemu-2.9.0/include/fpu/softfloat.h:151:5: error: unknown type name 'uint64_t'
     uint64_t low;
/usr/local/tools/qemu-2.9.0/include/fpu/softfloat.h:152:5: error: unknown type name 'uint16_t'
     uint16_t high;

Currently I am trying to understand the reason for this behavior.


Patricia López Cueva
R&D On-Board Software Engineer
TAS-F Cannes

De : Jiri Gaisler [mailto:jiri at]
Envoyé : jeudi 24 août 2017 10:29
À : LOPEZ CUEVA Patricia; users at
Objet : Re: Infinite loop on _Heap_Allocate

Have you applied leon3 patches for qemu from ?

These are needed to boot RTEMS binaries properly.


On 08/24/2017 10:22 AM, LOPEZ CUEVA Patricia wrote:
Hello all !

I've just installed rtems-4.8 on a Redhat 7 64 bits machine. I've installed the release version of rtems 4.8 and the following versions of the toolset:

-          gcc 4.2.1 with newlib 1.15.0

-          binutils 2.18

-          gdb 6.8

The compilation and installation of the toolset and rtems run without problem except for the documentation part which I disabled.

Then I installed the rtems-4.8 examples and tried to run hello_world_c on qemu leon3 with the command "qemu-system-sparc -nographic -M leon3_generic -cpu LEON3 -kernel hello.exe -s -S".

Neither error nor warning was present in the compilation or the execution process (nor the hello world message) and when I stop the execution it is always on the _Heap_Allocate function of cpukit/score/src/heapallocate.c file. Here is the backtrace:

(gdb) c

Program received signal SIGINT, Interrupt.
_Heap_Allocate (the_heap=0x40013e6c, size=<value optimized out>) at ../../../../../../rtems-4.8.0/c/src/../../cpukit/score/src/heapallocate.c:57
57            the_block = the_block->next, ++search_count)
(gdb) bt
#0  _Heap_Allocate (the_heap=0x40013e6c, size=<value optimized out>) at ../../../../../../rtems-4.8.0/c/src/../../cpukit/score/src/heapallocate.c:57
#1  0x4000b8c8 in _Workspace_Allocate_or_fatal_error (size=52) at ../../cpukit/../../../leon3/lib/include/rtems/score/wkspace.inl:37
#2  0x4000b2e4 in _User_extensions_Handler_initialization (number_of_extensions=1, initial_extensions=0x40012cc0) at ../../../../../../rtems-4.8.0/c/src/../../cpukit/score/src/userext.c:37
#3  0x40007860 in rtems_initialize_executive_early (configuration_table=0x40013930, cpu_table=0x40013908) at ../../../../../../rtems-4.8.0/c/src/../../cpukit/sapi/src/exinit.c:152
#4  0x40001924 in boot_card (argc=0, argv=0x0, envp=0x0) at ../../../../../../../../rtems-4.8.0/c/src/lib/libbsp/sparc/leon3/../../shared/bootcard.c:117
#5  0x400010dc in zerobss () at ../../../../../../../../rtems-4.8.0/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/start.S:339
#6  0x400010dc in zerobss () at ../../../../../../../../rtems-4.8.0/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/start.S:339
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) p *the_heap
$17 = {free_list = {prev_size = 0, size = 0, next = 0xfffc8040, prev = 0xfffc8040}, page_size = 8, min_block_size = 16, begin = 0xfffc8040, end = 0xfffd5e50, start = 0xfffc8040, final = 0xfffd5e48, stats = {instance = 0,
    size = 56848, free_size = 56840, min_free_size = 56840, free_blocks = 1, max_free_blocks = 1, used_blocks = 0, max_search = 0, allocs = 0, searches = 0, frees = 0, resizes = 0}}

It seems to be blocked on an infinite loop. I presume there has been a problem with the installation of rtems that I have not seen since this is a well proven version and it is the most basic example.

Would you have an idea of what the problem might be?

Thanks a lot in advance,
Patricia Lopez Cueva


users mailing list

users at<mailto:users at>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list