Don't see any problems here with valgrind.
Red Hat Enterprise Linux Server release 5.7 (Tikanga) [sqlite-amalgamation-3071100]$ gcc -g -o shell shell.c sqlite3.c -ldl -lpthread [sqlite-amalgamation-3071100]$ ./shell SQLite version 3.7.11 2012-03-20 11:35:50 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> create table a(b int); sqlite> [mblack@melb0113 sqlite-amalgamation-3071100]$ [sqlite-amalgamation-3071100]$ valgrind --leak-check=full ./shell ==28575== Memcheck, a memory error detector ==28575== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==28575== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==28575== Command: ./shell ==28575== SQLite version 3.7.11 2012-03-20 11:35:50 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> create table a(b int); sqlite> .quit ==28575== ==28575== HEAP SUMMARY: ==28575== in use at exit: 0 bytes in 0 blocks ==28575== total heap usage: 171 allocs, 171 frees, 126,074 bytes allocated ==28575== ==28575== All heap blocks were freed -- no leaks are possible ==28575== ==28575== For counts of detected and suppressed errors, rerun with: -v ==28575== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4) Michael D. Black Senior Scientist Advanced Analytics Directorate Advanced GEOINT Solutions Operating Unit Northrop Grumman Information Systems ________________________________ From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of Laszlo Boszormenyi [g...@debian.hu] Sent: Monday, March 26, 2012 12:58 PM To: Richard Hipp Cc: General Discussion of SQLite Database Subject: EXT :Re: [sqlite] memory handling problems in 3.710 - 3.7.11 Dear Richard, On Mon, 2012-03-26 at 08:20 -0400, Richard Hipp wrote: > On Sun, Mar 25, 2012 at 9:32 PM, Laszlo Boszormenyi <g...@debian.hu> > wrote: > On Debian and amd64 architecture SQLite3 has a severe problem. > If I just > start it, I can create a simple table like "create table a(b > int);". > However when I set "export MALLOC_CHECK_=1" then the mentioned > table > creation reports: > *** glibc detected *** sqlite3: free(): invalid pointer: > 0x00007fba85c30560 *** > > Usually, this kind of thing is an indication that your application > (not SQLite) is corrupting the heap, and SQLite just happen to have > the misfortune of being the first to bump into that corruption. We misunderstand each other somewhere. As I wrote, I just start sqlite3 itself. It's not embedded or used by anything else. Here is what happens on my amd64 box. julia login: gcs Password: Last login: Sat Mar 24 06:10:27 CET 2012 on tty1 Linux julia 3.2.0-2-amd64 #1 SMP Tue Mar 13 16:54:04 UTC 2012 x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. No mail. gcs@julia:~$ id gcs uid=1000(gcs) gid=1000(gcs) groups=1000(gcs),20(dialout),24(cdrom),25(floppy),29(audio),44(video),46(plugdev),112(kvm),132(uml-net) gcs@julia:~$ dpkg -l sqlite3 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ ii sqlite3 3.7.11-2 Command line interface for SQLite 3 gcs@julia:~$ sqlite3 --version 3.7.11 2012-03-20 11:35:50 00bb9c9ce4f465e6ac321ced2a9d0062dc364669 gcs@julia:~$ sqlite3 SQLite version 3.7.11 2012-03-20 11:35:50 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> create table a(b int); sqlite> [control+d] gcs@julia:~$ export MALLOC_CHECK_=1 gcs@julia:~$ sqlite3 SQLite version 3.7.11 2012-03-20 11:35:50 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> create table a(b int); *** glibc detected *** sqlite3: free(): invalid pointer: 0x00007f89909f78d0 *** sqlite> [control+d] gcs@julia:~$ export MALLOC_CHECK_=2 gcs@julia:~$ sqlite3 SQLite version 3.7.11 2012-03-20 11:35:50 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> create table a(b int); Aborted gcs@julia:~$ > Have you tried running your application using valgrind? You mean 'valgrind /bin/sh sqlite3'? Nope, only the following. gcs@julia:~$ valgrind sqlite3 ==14129== Memcheck, a memory error detector ==14129== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==14129== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==14129== Command: sqlite3 ==14129== SQLite version 3.7.11 2012-03-20 11:35:50 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> create table a(b int); sqlite> ==14129== ==14129== HEAP SUMMARY: ==14129== in use at exit: 127,884 bytes in 488 blocks ==14129== total heap usage: 923 allocs, 435 frees, 306,164 bytes allocated ==14129== ==14129== LEAK SUMMARY: ==14129== definitely lost: 60 bytes in 1 blocks ==14129== indirectly lost: 240 bytes in 10 blocks ==14129== possibly lost: 0 bytes in 0 blocks ==14129== still reachable: 127,584 bytes in 477 blocks ==14129== suppressed: 0 bytes in 0 blocks ==14129== Rerun with --leak-check=full to see details of leaked memory ==14129== ==14129== For counts of detected and suppressed errors, rerun with: -v ==14129== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 6) gcs@julia:~$ So let's do it again with --leak-check=full as seen below. gcs@julia:~$ valgrind --leak-check=full sqlite3 ==14158== Memcheck, a memory error detector ==14158== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==14158== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==14158== Command: sqlite3 ==14158== SQLite version 3.7.11 2012-03-20 11:35:50 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> create table a(b int); sqlite> ==14158== ==14158== HEAP SUMMARY: ==14158== in use at exit: 127,844 bytes in 488 blocks ==14158== total heap usage: 923 allocs, 435 frees, 306,018 bytes allocated ==14158== ==14158== 300 (60 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 27 of 53 ==14158== at 0x402894D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==14158== by 0x4FF899C: nss_parse_service_list (nsswitch.c:626) ==14158== by 0x4FF9171: __nss_database_lookup (nsswitch.c:167) ==14158== by 0x5CE11EF: ??? ==14158== by 0x5CE1D94: ??? ==14158== by 0x4FB8ADC: getpwuid_r@@GLIBC_2.2.5 (getXXbyYY_r.c:256) ==14158== by 0x4FB83CE: getpwuid (getXXbyYY.c:117) ==14158== by 0x10BD9F: find_home_dir (shell.c:2606) ==14158== by 0x10ABFD: main (shell.c:2674) ==14158== ==14158== LEAK SUMMARY: ==14158== definitely lost: 60 bytes in 1 blocks ==14158== indirectly lost: 240 bytes in 10 blocks ==14158== possibly lost: 0 bytes in 0 blocks ==14158== still reachable: 127,544 bytes in 477 blocks ==14158== suppressed: 0 bytes in 0 blocks ==14158== Reachable blocks (those to which a pointer was found) are not shown. ==14158== To see them, rerun with: --leak-check=full --show-reachable=yes ==14158== ==14158== For counts of detected and suppressed errors, rerun with: -v ==14158== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 8 from 6) In short, I think this bug somehow related to SQLite3 itself. Should I install a bare system with SQLite3 and check if it's working there? I'm also open for any suggestions what should I do to narrow down this issue. Please note that the x86 version downloaded from your site is working. It seems to be: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped My own 64 bit version: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xa8e7b0e05e9eb87f562037241417a14eace10f12, stripped Thanks, Laszlo/GCS _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
