aff486b6a0
The memory leak can be reproduced by using an arbitrary RTOS and valgrind: $ valgrind --leak-check=full --show-leak-kinds=all [...] ==9656== 224 (80 direct, 144 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 3 ==9656== at 0x483CD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==9656== by 0x1C541A: os_alloc (rtos.c:79) ==9656== by 0x1C569E: os_alloc_create (rtos.c:111) ==9656== by 0x1C569E: rtos_create (rtos.c:153) ==9656== by 0x1AE332: target_configure (target.c:4899) ==9656== by 0x1AF228: jim_target_configure (target.c:4952) ==9656== by 0x1C9EF9: command_unknown (command.c:1066) ==9656== by 0x313284: JimInvokeCommand (jim.c:10364) ==9656== by 0x313FB6: Jim_EvalObj (jim.c:10814) ==9656== by 0x3154A3: Jim_EvalFile (jim.c:11207) ==9656== by 0x316015: Jim_SourceCoreCommand (jim.c:15230) ==9656== by 0x313284: JimInvokeCommand (jim.c:10364) ==9656== by 0x313B8B: JimEvalObjList (jim.c:10605) [...] Change-Id: I2cd41a154fb8570842601ff4e3e76502f5908f49 Signed-off-by: Marc Schink <dev@zapb.de> Reviewed-on: http://openocd.zylin.com/5479 Tested-by: jenkins Reviewed-by: Moritz Fischer <moritzf@google.com> Reviewed-by: Tomas Vanek <vanekt@fbl.cz> |
||
---|---|---|
.. | ||
ChibiOS.c | ||
chromium-ec.c | ||
eCos.c | ||
embKernel.c | ||
FreeRTOS.c | ||
hwthread.c | ||
linux_header.h | ||
linux.c | ||
Makefile.am | ||
mqx.c | ||
nuttx_header.h | ||
nuttx.c | ||
rtos_chibios_stackings.c | ||
rtos_chibios_stackings.h | ||
rtos_ecos_stackings.c | ||
rtos_ecos_stackings.h | ||
rtos_embkernel_stackings.c | ||
rtos_embkernel_stackings.h | ||
rtos_mqx_stackings.c | ||
rtos_mqx_stackings.h | ||
rtos_standard_stackings.c | ||
rtos_standard_stackings.h | ||
rtos_ucos_iii_stackings.c | ||
rtos_ucos_iii_stackings.h | ||
rtos.c | ||
rtos.h | ||
ThreadX.c | ||
uCOS-III.c |