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)"
>
> ===========<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.
>
>   
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to