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)"

===========<OUTPUT>===========
==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)
===========</OUTPUT>===========

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? </conjecture>

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

Reply via email to