forked from auracaster/openocd
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>