在contiki程序中使用malloc

Question

Consider the following contiki program.

#include<stdio.h>
#include"contiki.h"
#include <stdlib.h>

static char *mem;
static int x;
/*---------------------------------------------------------------------------*/
PROCESS(test, "test");
AUTOSTART_PROCESSES(&test);
/*---------------------------------------------------------------------------*/
PROCESS_THREAD(test, ev, data)
{
  PROCESS_BEGIN();
  printf("before malloc\n");
  mem=(char*)malloc(10);
  for(x=0;x<10;x++)
     mem[x]=x+1;
  printf("after malloc\n");
  PROCESS_END();
}

when this program is compiled for native/z1/wismote/cooja it executes perfectly fine and both the printf statements are executed, but when compiled for mbxxx target, and then executed on hardware, only the first printf statements is executed and the code gets stuck in the malloc. Any guess or reason behind this behaviour? I am also attaching the GDB trace here.

(gdb) mon reset init
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08000efc msp: 0x20000500
(gdb) b test.c:16
Breakpoint 1 at 0x8000ec8: file test.c, line 16.
(gdb) b test.c:17
Breakpoint 2 at 0x8000ece: file test.c, line 17.
(gdb) b test.c:18
Breakpoint 3 at 0x8000ed8: file test.c, line 18.
(gdb) load
Loading section .isr_vector, size 0x84 lma 0x8000000
Loading section .text, size 0xc5c4 lma 0x8000084
Loading section .data, size 0x660 lma 0x800c648
Start address 0x8000084, load size 52392
Transfer rate: 15 KB/sec, 8732 bytes/write.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.

Breakpoint 1, process_thread_test (process_pt=0x2000050c <test+12>, ev=129 '\201', data=0x0) at test.c:16
16      printf("before malloc\n");
(gdb) c
Continuing.

Breakpoint 2, process_thread_test (process_pt=0x2000050c <test+12>, ev=<optimized out>, 
    data=<optimized out>) at test.c:17
17  mem=(char*)malloc(10);
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
Default_Handler () at ../../cpu/stm32w108/hal/micro/cortexm3/stm32w108/crt-stm32w108.c:87
87  {
(gdb) bt
#0  Default_Handler () at ../../cpu/stm32w108/hal/micro/cortexm3/stm32w108/crt-stm32w108.c:87
#1  <signal handler called>
#2  0x08000440 in _malloc_r ()
#3  0x08000ed4 in process_thread_test (process_pt=0x2000050c <certificate_check+12>, ev=<optimized out>, 
    data=<optimized out>) at test.c:17
#4  0x0800272c in call_process (p=0x20000500 <test>, ev=<optimized out>, data=<optimized out>)
    at ../../core/sys/process.c:190
#5  0x080028e6 in process_post_synch (p=<optimized out>, ev=ev@entry=129 '\201', data=<optimized out>)
    at ../../core/sys/process.c:366
#6  0x0800291a in process_start (p=<optimized out>, arg=arg@entry=0x0) at ../../core/sys/process.c:120
#7  0x08002964 in autostart_start (processes=<optimized out>) at ../../core/sys/autostart.c:57
#8  0x08001134 in main () at ../../platform/mbxxx/./contiki-main.c:210
(gdb)

Answer 1

Ahhh... Finally figured out the problem. This particular problem was there because stm32w108 was not configured to use dynamic memory.

All that was needed to be done was, to open the the following file: contiki-2.7/cpu/stm32w108/hal/micro/cortexm3/stm32w108/crt-stm32w108.c and add #define USE_HEAP at the top of the file or before the _sbrk implementation! The heap size can also be modified here, not from the linker script, although the stack size

A side note: It is a really bad idea to use dynamic memory allocation in embedded systems, so avoid it! Its filthy trust me! Eventually I will also remove any dynamic memory allocation references! :)