3
Рассмотрите следующую программу contiki.Использование malloc в программах contiki
#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();
}
, когда эта программа составлена для родного/z1/wismote/cooja он выполняет прекрасно, и оба PRINTF инструкции выполняются, но при компиляции для mbxxx цели, а затем выполняется на оборудовании, только первые PRINTF заявление и код застревает в malloc. Любая догадка или причина этого поведения? Я также прикрепляю трассировку GDB.
(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>, [email protected]=129 '\201', data=<optimized out>)
at ../../core/sys/process.c:366
#6 0x0800291a in process_start (p=<optimized out>, [email protected]=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)
Похоже, вы используете вариант реализации 'malloc' Doug Lea в вашей системе. Вам понадобится версия библиотеки C с символами отладки, чтобы узнать, где внутри функции 'malloc' она застревает. Вероятно, это проблема системы, и она может быть даже специфичной для вашей установки, поэтому очень мало кто-то, кроме того, что может помочь вам конкретному сообществу разработчиков. Удачи! – jxh
@jxh это был помечен как 'contiki', который является встроенной ОС. – errordeveloper
@errordeveloper: Извините, это значит, что вы верите, что мой совет был неправильным, и что проблема не зависит от конкретной системы или не связана с конкретной установкой? – jxh