[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Tinycc-devel] libtcc memory leak

From: James Buren
Subject: [Tinycc-devel] libtcc memory leak
Date: Sun, 2 Nov 2014 14:09:24 -0800

When using tcc_compile_string() to compile a simple function, I have found a 
memory leak that was reported by valgrind. It appears to be allocated at line 
5972 in function decl0 in the file tccgen.c. It appears to happen after 
tcc_strdup() is called and the loop containing the asm_label variable ends, 
either via a break or return statement. The pointer appears to be lost, thus 
leaking the memory allocated by tcc_strdup().

Here is my valgrind output:
==6286== Memcheck, a memory error detector
==6286== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==6286== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==6286== Command: ./test
==6286== Parent PID: 3345
==6286== HEAP SUMMARY:
==6286==     in use at exit: 97 bytes in 6 blocks
==6286==   total heap usage: 3,199 allocs, 3,193 frees, 822,391 bytes allocated
==6286== 97 bytes in 6 blocks are definitely lost in loss record 1 of 1
==6286==    at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==6286==    by 0x40199F: tcc_malloc (libtcc.c:215)
==6286==    by 0x401A6B: tcc_strdup (libtcc.c:255)
==6286==    by 0x41639E: decl0 (tccgen.c:5972)
==6286==    by 0x416A38: decl (tccgen.c:6162)
==6286==    by 0x402D4A: tcc_compile (libtcc.c:791)
==6286==    by 0x402EA1: tcc_compile_string (libtcc.c:825)
==6286==    by 0x401755: main (in /home/ryuo/ndisapi/test)
==6286== LEAK SUMMARY:
==6286==    definitely lost: 97 bytes in 6 blocks
==6286==    indirectly lost: 0 bytes in 0 blocks
==6286==      possibly lost: 0 bytes in 0 blocks
==6286==    still reachable: 0 bytes in 0 blocks
==6286==         suppressed: 0 bytes in 0 blocks
==6286== For counts of detected and suppressed errors, rerun with: -v
==6286== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)

I would fix it myself, but I am not familiar with the innards well enough to 
propose a viable patch. Thank you.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]