Re: [sqlite] Valgrind, writeJournalHdr and Syscall param write(buf) points to uninitialised byte(s).
On ti., 2008-12-09 at 11:29 -0500, D. Richard Hipp wrote: > On Dec 9, 2008, at 11:23 AM, Kent Dahl wrote: > > After running valgrind on my program that is using sqlite (3.6.6.2, > > statically linked on Linux, Ubuntu 8.10) for a while, carving away all > > the problems caused by my own code, I was left with the "Syscall param > > write(buf) points to uninitialised byte(s)" error reported within the > > call from writeJournalHdr. > > The uninitialized space is harmless. But if it worries you there is a > patch. http://www.sqlite.org/cvstrac/chngview?cn=5968 Thanks, just the confirmation and additional information I was looking for. > > (Sorry to be mentioning 'valgrind', which seems to be akin to a > > four-letter word, on this list... ;) > > > > Why do you think this? We love valgrind. When I first saw this error in valgrind, Googling pointed me to the old PRNG issue with k[256] being uninitialized, quite a few ranting messages about valgrind, the KDE and sqlite bugs pointing back and forth at each other and a finally "funny-hmm" commit message ranting. So I thought it prudent to don my asbestos underpants before posting this. :) > It's the useless and > annoying warning messages from VC++ that we hate. Ah, thankfully I personally only worry about warnings that are reproducible on Linux... Unfortunately, my code still has to work on VC++. :( -- Mvh/Regards, Kent Dahl Software Developer Industrial Control Design AS Phone: +47 93 07 32 30 Breivika Industriveg 63 N-6018 Ålesund Norway [EMAIL PROTECTED] www.icd.no The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the System Manager [EMAIL PROTECTED] and delete the material from any computer. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Valgrind, writeJournalHdr and Syscall param write(buf) points to uninitialised byte(s).
Hi, i remember the posts you mention, and I know these error reports from valgrind. I get them outside of sqlite also, and have learned to ignore them. Martin Kent Dahl schrieb: > Hi. > > After running valgrind on my program that is using sqlite (3.6.6.2, > statically linked on Linux, Ubuntu 8.10) for a while, carving away all > the problems caused by my own code, I was left with the "Syscall param > write(buf) points to uninitialised byte(s)" error reported within the > call from writeJournalHdr. > > I saw a similar post in the archives, which may be the same issue: > http://www.mail-archive.com/sqlite-users@sqlite.org/msg38091.html > But the replies don't explain on _why_ it isn't a problem, hence my > continued concern and this email. > > Is this covered in a bug issue? The old #536 ticket looks similar, but > as far as I can tell, the resolution mentioned is more on the PRNG code. > (And the PRNG fix for valgrind is in 3.6.6.2.) > http://www.sqlite.org/cvstrac/tktview?tn=536 > > Output from valgrind, using the example code at the bottom of > http://www.sqlite.org/quickstart.html > and run as: > valgrind ./testsql test.db "create table testtable(id INTEGER)" > > == > ==18100== Syscall param write(buf) points to uninitialised byte(s) > ==18100==at 0x40007D2: (within /lib/ld-2.8.90.so) > ==18100==by 0x8066B08: writeJournalHdr (sqlite3.c:12420) > ==18100==by 0x8066D5F: pager_open_journal (sqlite3.c:31731) > ==18100==by 0x80700A3: sqlite3BtreeBeginTrans (sqlite3.c:35905) > ==18100==by 0x809956E: sqlite3VdbeExec (sqlite3.c:48875) > ==18100==by 0x80885D7: sqlite3_step (sqlite3.c:45476) > ==18100==by 0x8088F31: sqlite3_exec (sqlite3.c:66489) > ==18100== Address 0x42eb004 is 36 bytes inside a block of size 1,032 > alloc'd > ==18100==at 0x4025D2E: malloc (vg_replace_malloc.c:207) > ==18100==by 0x805AE7A: sqlite3MemMalloc (sqlite3.c:12830) > ==18100==by 0x8049CC8: mallocWithAlarm (sqlite3.c:15992) > ==18100==by 0x8049D96: sqlite3Malloc (sqlite3.c:16015) > ==18100==by 0x804AF34: pcache1Alloc (sqlite3.c:28155) > ==18100==by 0x804B05C: sqlite3PageMalloc (sqlite3.c:28219) > ==18100==by 0x80685AB: sqlite3BtreeFactory (sqlite3.c:30603) > ==18100==by 0x806EED0: openDatabase (sqlite3.c:85463) > == > > Could it be something like the journal header only is partly filled, but > needs to be of certain block-size on disk, leaving trailing > uninitialized bytes? > > I'm not necessarily hoping for a solution as such. A pointer to a bug or > code comment that explains why it is safe would suffice nicely. > > (Sorry to be mentioning 'valgrind', which seems to be akin to a > four-letter word, on this list... ;) > > TIA. > > ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Valgrind, writeJournalHdr and Syscall param write(buf) points to uninitialised byte(s).
On Dec 9, 2008, at 11:23 AM, Kent Dahl wrote: > Hi. > > After running valgrind on my program that is using sqlite (3.6.6.2, > statically linked on Linux, Ubuntu 8.10) for a while, carving away all > the problems caused by my own code, I was left with the "Syscall param > write(buf) points to uninitialised byte(s)" error reported within the > call from writeJournalHdr. > > The uninitialized space is harmless. But if it worries you there is a patch. http://www.sqlite.org/cvstrac/chngview?cn=5968 > (Sorry to be mentioning 'valgrind', which seems to be akin to a > four-letter word, on this list... ;) > Why do you think this? We love valgrind. It's the useless and annoying warning messages from VC++ that we hate. D. Richard Hipp [EMAIL PROTECTED] ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Valgrind, writeJournalHdr and Syscall param write(buf) points to uninitialised byte(s).
Hi. After running valgrind on my program that is using sqlite (3.6.6.2, statically linked on Linux, Ubuntu 8.10) for a while, carving away all the problems caused by my own code, I was left with the "Syscall param write(buf) points to uninitialised byte(s)" error reported within the call from writeJournalHdr. I saw a similar post in the archives, which may be the same issue: http://www.mail-archive.com/sqlite-users@sqlite.org/msg38091.html But the replies don't explain on _why_ it isn't a problem, hence my continued concern and this email. Is this covered in a bug issue? The old #536 ticket looks similar, but as far as I can tell, the resolution mentioned is more on the PRNG code. (And the PRNG fix for valgrind is in 3.6.6.2.) http://www.sqlite.org/cvstrac/tktview?tn=536 Output from valgrind, using the example code at the bottom of http://www.sqlite.org/quickstart.html and run as: valgrind ./testsql test.db "create table testtable(id INTEGER)" == ==18100== Syscall param write(buf) points to uninitialised byte(s) ==18100==at 0x40007D2: (within /lib/ld-2.8.90.so) ==18100==by 0x8066B08: writeJournalHdr (sqlite3.c:12420) ==18100==by 0x8066D5F: pager_open_journal (sqlite3.c:31731) ==18100==by 0x80700A3: sqlite3BtreeBeginTrans (sqlite3.c:35905) ==18100==by 0x809956E: sqlite3VdbeExec (sqlite3.c:48875) ==18100==by 0x80885D7: sqlite3_step (sqlite3.c:45476) ==18100==by 0x8088F31: sqlite3_exec (sqlite3.c:66489) ==18100== Address 0x42eb004 is 36 bytes inside a block of size 1,032 alloc'd ==18100==at 0x4025D2E: malloc (vg_replace_malloc.c:207) ==18100==by 0x805AE7A: sqlite3MemMalloc (sqlite3.c:12830) ==18100==by 0x8049CC8: mallocWithAlarm (sqlite3.c:15992) ==18100==by 0x8049D96: sqlite3Malloc (sqlite3.c:16015) ==18100==by 0x804AF34: pcache1Alloc (sqlite3.c:28155) ==18100==by 0x804B05C: sqlite3PageMalloc (sqlite3.c:28219) ==18100==by 0x80685AB: sqlite3BtreeFactory (sqlite3.c:30603) ==18100==by 0x806EED0: openDatabase (sqlite3.c:85463) == Could it be something like the journal header only is partly filled, but needs to be of certain block-size on disk, leaving trailing uninitialized bytes? I'm not necessarily hoping for a solution as such. A pointer to a bug or code comment that explains why it is safe would suffice nicely. (Sorry to be mentioning 'valgrind', which seems to be akin to a four-letter word, on this list... ;) TIA. -- Mvh/Regards, Kent Dahl Software Developer Industrial Control Design AS Phone: +47 93 07 32 30 Breivika Industriveg 63 N-6018 Ålesund Norway [EMAIL PROTECTED] www.icd.no The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the System Manager [EMAIL PROTECTED] and delete the material from any computer. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
