It was thus said that the Great grischka once stated: > Sean Conner wrote: > >>As to the patch I think that > >> + s1->runtime_mem = NULL; > >>would break tcc_relocate and I don't see why you need it. > > > > I did that so that the call to tcc_delete() wouldn't crash when it tried > >to free s->runtime_mem that might contain a garbage value (since > >tcc_relocate_ex() would never set that field). Good thing too, because > >tcc_new() *might not* be initializing NULL pointers correctly [1]. > > Well, from my point of view that line would not fix tcc_new > but cause a memory leak for tcc_relocate.
Here's the output from valgrind running tcc using the current source code: [spc]lucy:~/apps/tinycc>valgrind ./tcc -c libtcc.c -DTCC_TARGET_I386 -DONE_SOURCE ==10945== Memcheck, a memory error detector. ==10945== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==10945== Using LibVEX rev 1575, a library for dynamic binary translation. ==10945== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==10945== Using valgrind-3.1.1, a dynamic binary instrumentation framework. ==10945== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==10945== For more details, rerun with: -v ==10945== ==10945== ==10945== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1) ==10945== malloc/free: in use at exit: 0 bytes in 0 blocks. ==10945== malloc/free: 93,402 allocs, 93,402 frees, 41,400,839 bytes allocated. ==10945== For counts of detected errors, rerun with: -v ==10945== All heap blocks were freed -- no leaks are possible. And the output with the patch: [spc]lucy:~/apps/tinycc>valgrind ./tcc -c libtcc.c -DTCC_TARGET_I386 -DONE_SOURCE ==11070== Memcheck, a memory error detector. ==11070== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==11070== Using LibVEX rev 1575, a library for dynamic binary translation. ==11070== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==11070== Using valgrind-3.1.1, a dynamic binary instrumentation framework. ==11070== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==11070== For more details, rerun with: -v ==11070== ==11070== ==11070== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1) ==11070== malloc/free: in use at exit: 0 bytes in 0 blocks. ==11070== malloc/free: 49,772 allocs, 49,772 frees, 19,867,951 bytes allocated. ==11070== For counts of detected errors, rerun with: -v ==11070== All heap blocks were freed -- no leaks are possible. And further more, here's a program I wrote that uses tcc_relocate_ex(): [spc]lucy:~/source/synthesis>valgrind ./m >/dev/null ==11077== Memcheck, a memory error detector. ==11077== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==11077== Using LibVEX rev 1575, a library for dynamic binary translation. ==11077== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==11077== Using valgrind-3.1.1, a dynamic binary instrumentation framework. ==11077== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==11077== For more details, rerun with: -v ==11077== f1 1.128470000 f2 0.369861000 ==11077== ==11077== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 22 from 2) ==11077== malloc/free: in use at exit: 1,109 bytes in 7 blocks. ==11077== malloc/free: 7,441 allocs, 7,434 frees, 1,867,222 bytes allocated. ==11077== For counts of detected errors, rerun with: -v ==11077== searching for pointers to 7 not-freed blocks. ==11077== checked 179,256 bytes. ==11077== ==11077== LEAK SUMMARY: ==11077== definitely lost: 0 bytes in 0 blocks. ==11077== possibly lost: 0 bytes in 0 blocks. ==11077== still reachable: 1,109 bytes in 7 blocks. ==11077== suppressed: 0 bytes in 0 blocks. ==11077== Reachable blocks (those to which a pointer was found) are not shown. ==11077== To see them, rerun with: --show-reachable=yes (The program loads and compiles the same file twice (with some differences in what's defined) using different TCC states for each file and runs both---what you are seeing is how long it took to compile the file each time---valgrind is affecting the speed of the first compile). > > -spc (But I would feel safer with the NULL pointer assignment ... ) > > (That's what I suspected ...) -spc (Well, I do work in the QA department at my company ... ) _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel