Hi, I think you're going to have to be a bit more rigorous about what you're testing if you're hoping for a fix.
In your root message you posted a bit of code and said you'd found a leak in v2.8.17 of the library. Then you said the leak was present in v2.8.17 and v3.3.6 (the valgrind of 'bash' post) and showed the header from the sqlite shell v3.3.6 Then you said the leak was present in 3.3.6 and posted a valgrind log of the sqlite shell v3.2.2 run from a directory .../3.3.6. You didn't say what hardware you're running and in the latter cases where you're testing the shell it would be useful if you said what you DID in the shell. I just compiled valgrind-3.2.0 (vs your valgrind-3.1.1) on a Pentium 1 machine and ran it against a locally built 3.3.6 shell. All I did in the shell was issue a ".q" to quit. My log is rather different to yours, as shown below: deb:~/valgrind-3.2.0# uname -a Linux deb 2.6.8-3-386 #1 Sat Jul 15 09:26:40 UTC 2006 i586 GNU/Linux deb:~/valgrind-3.2.0# deb:~/valgrind-3.2.0# valgrind --leak-check=full sqlite3 ==19856== Memcheck, a memory error detector. ==19856== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==19856== Using LibVEX rev 1606, a library for dynamic binary translation. ==19856== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==19856== Using valgrind-3.2.0, a dynamic binary instrumentation framework. ==19856== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==19856== For more details, rerun with: -v ==19856== --19856-- DWARF2 CFI reader: unhandled CFI instruction 0:50 --19856-- DWARF2 CFI reader: unhandled CFI instruction 0:50 SQLite version 3.3.6 Enter ".help" for instructions sqlite> .q ==19856== ==19856== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 1) ==19856== malloc/free: in use at exit: 31 bytes in 2 blocks. ==19856== malloc/free: 8 allocs, 6 frees, 1,536 bytes allocated. ==19856== For counts of detected errors, rerun with: -v ==19856== searching for pointers to 2 not-freed blocks. ==19856== checked 86,964 bytes. ==19856== ==19856== 6 bytes in 1 blocks are definitely lost in loss record 1 of 2 ==19856== at 0x401B6E7: malloc (vg_replace_malloc.c:149) ==19856== by 0x804CC44: find_home_dir (shell.c:1580) ==19856== by 0x804D169: main (shell.c:1806) ==19856== ==19856== ==19856== 25 bytes in 1 blocks are definitely lost in loss record 2 of 2 ==19856== at 0x401B6E7: malloc (vg_replace_malloc.c:149) ==19856== by 0x804D182: main (shell.c:1807) ==19856== ==19856== LEAK SUMMARY: ==19856== definitely lost: 31 bytes in 2 blocks. ==19856== possibly lost: 0 bytes in 0 blocks. ==19856== still reachable: 0 bytes in 0 blocks. ==19856== suppressed: 0 bytes in 0 blocks. ==19856== Reachable blocks (those to which a pointer was found) are not shown. ==19856== To see them, rerun with: --show-reachable=yes Looking at the code in shell.c these are valid leak reports but they're in the shell, not the library, and I suspect there will be plenty of things with a higher priority than adding code to explicitly free a couple of small buffers which will be freed anyway when the shell is closed. Since all I did was issue a ".q" it's not a valid test of the library, so I did another run on the following session and the valgrind report was EXACTLY the same as the simple ".q" test above - two trivial leaks reported at lines 1806/7 in shell.c. SQLite version 3.3.6 Enter ".help" for instructions sqlite> create table fred(a,b,c); sqlite> insert into fred values(1,2,3); sqlite> select * from fred; 1|2|3 sqlite> .q As you don't say what you did in the shell to get those leak reports it's hard to duplicate your results. If you post what you did I'll re-run the valgrind test. Martin
