Re: [sqlite] Using SQLite3 on On-Time RTOS ...
ma., 27.04.2009 kl. 14.58 +0200, skrev Kent Dahl: > We've been giving the SQLite 3.6.10 amalgamation source code for Windows > a try against RTOS 5.14 and it compiled out of the box. However, we ran > into some linker and run-time errors. After a fair amount of > experimenting, we got it up and running, but only towards an in-memory > database. We still have problems opening existing or creating database > files. [...] > Finally we had something that linked and ran, but only towards in-memory > database. When we tried to open an existing database (or create a new > one) using the sqlite3_open_v2 API, it kept returning SQLITE_NOMEM(7). > When I tried debugging this, I got as far as the sqlite3BtreeFactory > call, but because of the breakpointing problems I didn't get much > further. Unfortunately, work priorities shifted so I didn't have much time to dig futher into the disk problems. In the off chance that someone else might find this useful, I'm including the patches I had so far when I stopped investigating. These are towards the 3.6.10 amalagamation source and are not too clean, but might save someone else trying SQLite3 on On-Time RTOS a little time getting started... Please let me (and the list) know if anyone has any further progress. -- Mvh/Regards, Kent Dahl Software Developer Industrial Control Design AS Phone: +47 93 07 32 30 Breivika Industriveg 63 N-6018 Ålesund Norway k...@icd.no 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 i...@icd.no 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).
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
[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
