It is not related to a particular SQL request. And the errors are corrected by using calloc instead of malloc in mem1.c and mem2.c
Maybe sqlite team prefer to let the caller memset the allocated area ? Anyway, For this one : ==32575== Conditional jump or move depends on uninitialised value(s) ==32575== at 0x17F93C: sqlite3PagerSharedLock (in main.exe) ==32575== by 0x1887D0: lockBtree (in main.exe) ==32575== by 0x188FB1: sqlite3BtreeBeginTrans (in main.exe) ==32575== by 0x1A0723: sqlite3VdbeExec (in main.exe) ==32575== by 0x19A76A: sqlite3Step (in main.exe) ==32575== by 0x19A93F: sqlite3_step (in main.exe) ==32575== by 0x1C6863: sqlite3_exec (in main.exe) ==32575== by 0x13764E: main (main.c:341) ==32575== Uninitialised value was created by a heap allocation ==32575== at 0x4C2779D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==32575== by 0x16DAE4: sqlite3MemMalloc (in main.exe) ==32575== by 0x16E4DF: mallocWithAlarm (in main.exe) ==32575== by 0x16E57A: sqlite3Malloc (in main.exe) ==32575== by 0x168503: sqlcipher_malloc (in main.exe) ==32575== by 0x16905E: sqlcipher_codec_ctx_set_pagesize (in main.exe) ==32575== by 0x1691DD: sqlcipher_codec_ctx_init (in main.exe) ==32575== by 0x167F96: sqlite3CodecAttach (in main.exe) ==32575== by 0x168096: sqlite3_key (in main.exe) ==32575== by 0x137191: main (main.c:255) The SQL request is : SELECT cast(CPU_ID as integer)||\",\"||STRFTIME(\"%Y-%m-%d %H:%M:00\", TMS_LOAD)||\",\"||case when avg(CPU_PRC_PROCESS_TIME) < -1 then \"-1\" else avg(CPU_PRC_PROCESS_TIME)end||\",\"||case when avg(CPU_PRC_IDLE) < -1 then \"-1\" else avg(CPU_PRC_IDLE)end||\",\"||case when avg(CPU_PRC_IOWAIT) < -1 then \"-1\" else avg(CPU_PRC_IOWAIT) end FROM METR_CPU JOIN PRM_LOAD ON PK_LOAD_ID = FK_LOAD_ID GROUP BY CPU_ID, STRFTIME(\"%Y-%m-%d %H:%M:00\", TMS_LOAD);" 2012/10/17 Richard Hipp <d...@sqlite.org> > On Wed, Oct 17, 2012 at 5:18 PM, Alfred Sawaya <alf...@huji.fr> wrote: > > > The list block big messages... > > > > Here is a pastebin : http://pastebin.com/raw.php?i=QjN18m4h > > > > Can you show us what SQL you are running in order to get these errors? > > > > > > 2012/10/17 Richard Hipp <d...@sqlite.org> > > > > > On Wed, Oct 17, 2012 at 4:56 PM, Alfred Sawaya <alf...@huji.fr> wrote: > > > > > > > I send you the valgrind report, in attached file. > > > > > > > > > > This mailing list deletes attachments. Please include the valgrind > > report > > > inline. Thanks. > > > > > > > > > > > > > > I use sqlite with sqlcipher but it is not a sqlcipher related issue I > > > think > > > > (please see the sqlcipher team reply : > > > > https://github.com/sqlcipher/sqlcipher/issues/33 ). > > > > > > > > Thank you. > > > > > > > > 2012/10/17 Richard Hipp <d...@sqlite.org> > > > > > > > > > On Wed, Oct 17, 2012 at 4:36 PM, Richard Hipp <d...@sqlite.org> > > wrote: > > > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 17, 2012 at 4:33 PM, Alfred Sawaya <alf...@huji.fr> > > > wrote: > > > > > > > > > > > >> Hello, > > > > > >> > > > > > >> > > > > > >> Sqlite has some minor valgrind issues (some memory area point to > > > > > >> unitialized bytes). > > > > > >> > > > > > > > > > > > > Really? We run many of our test cases here through valgrind and > > > don't > > > > > see > > > > > > any problems. Can you be more specific? > > > > > > > > > > > > > > > > See checklist items 13f and 13g: > > > > > http://www.sqlite.org/checklists/3071400#c13 > > > > > > > > > > > > > > > > > > > > > > > > > > > >> You can easily avoid this by replacing malloc by calloc in > > > > src/mem1.c:84 > > > > > >> and src/mem2.c:255 > > > > > >> > > > > > >> Is it possible to integrate those improvements into the mainline > > of > > > > > >> Sqlite ? > > > > > >> > > > > > >> Thank you, > > > > > >> > > > > > >> Alfred. > > > > > >> > > > > > >> -- > > > > > >> > > > > > >> http://alfred.sawaya.tel > > > > > >> > > > > > >> .''`. > > > > > >> : :' : .:: Alfred Sawaya ::. > > > > > >> `. `'` > > > > > >> `- > > > > > >> _______________________________________________ > > > > > >> sqlite-users mailing list > > > > > >> sqlite-users@sqlite.org > > > > > >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > D. Richard Hipp > > > > > > d...@sqlite.org > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > D. Richard Hipp > > > > > d...@sqlite.org > > > > > _______________________________________________ > > > > > sqlite-users mailing list > > > > > sqlite-users@sqlite.org > > > > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > http://alfred.sawaya.tel > > > > > > > > .''`. > > > > : :' : .:: Alfred Sawaya ::. > > > > `. `'` > > > > `- > > > > > > > > _______________________________________________ > > > > sqlite-users mailing list > > > > sqlite-users@sqlite.org > > > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > > > > > > > > > > > > > > > -- > > > D. Richard Hipp > > > d...@sqlite.org > > > _______________________________________________ > > > sqlite-users mailing list > > > sqlite-users@sqlite.org > > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > > > > > > > > > -- > > > > http://alfred.sawaya.tel > > > > .''`. > > : :' : .:: Alfred Sawaya ::. > > `. `'` > > `- > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@sqlite.org > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > > > > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- http://alfred.sawaya.tel .''`. : :' : .:: Alfred Sawaya ::. `. `'` `- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
