mycmos <[EMAIL PROTECTED]> wrote: > > I believe the memory leak exists. The following is > excerpt from sqlite-3.3.6 in valgrind (In fact, the > sqlite-2.8.17 in valgrind is similar): > > [EMAIL PROTECTED] /data/lfs/sqlite-3.3.6]# valgrind > --leak-check=full ./sqlite3 [...] > ==11765== > ==11765== 27 bytes in 1 blocks are definitely lost in > loss record 1 of 4 > ==11765== at 0x401B46D: malloc > (vg_replace_malloc.c:149) > ==11765== by 0x80958E1: xmalloc (in /bin/bash) > ==11765== by 0x8069D65: execute_command_internal > (in /bin/bash) > ==11765== by 0x8099EBB: parse_and_execute (in > /bin/bash) > ==11765== by 0x807E28A: command_substitute (in > /bin/bash) > ==11765== by 0x8081F74: (within /bin/bash) > ==11765== by 0x8081C03: (within /bin/bash) > ==11765== by 0x80835A1: (within /bin/bash) > ==11765== by 0x806A901: execute_command_internal > (in /bin/bash) > ==11765== by 0x806C67F: execute_command (in > /bin/bash) > ==11765== by 0x806D7C3: (within /bin/bash) > ==11765== by 0x806A4F6: execute_command_internal > (in /bin/bash)
It appears that you are in fact running /bin/bash, not SQLite, and finding memory leaks there. Perhaps "sqlite3" is really a shell script on your system. Try running valgrind on a real sqlite3 executable and I believe you will find that there are no memory leaks. -- D. Richard Hipp <[EMAIL PROTECTED]>
