Hi Richard,
sqlite3Corrupt does trigger.
Callstack dump:
#0 00000000 decodeFlags(pPage=0xa026a4cc, flagByte=0) (SQLite\btree.c:1325)
#1 A000C1F8 btreeInitPage(pPage=0xa026a4cc) (SQLite\btree.c:1360)
#2 A000CB88 getAndInitPage(pBt=0xa025bc28, pgno=1, ppPage=0xa0269f14)
(SQLite\btree.c:1562)
#3 A0011520 moveToRoot(pCur=0xa0269eb8) (SQLite\btree.c:4038)
#4 A0011B40 sqlite3BtreeFirst(pCur=0xa0269eb8, pRes=0xa02525d8)
(SQLite\btree.c:4143)
#5 A00879D0 sqlite3VdbeExec(p=0xa026a038) (SQLite\vdbe.c:4542)
#6 A008BB78 sqlite3Step(p=0xa026a038) (SQLite\vdbeapi.c:344)
#7 A008BEC8 sqlite3_step(pStmt=0xa026a038) (SQLite\vdbeapi.c:403)
#8 A003C018 sqlite3_exec(db=0xa025b858, zSql=0xa0268e88 "SELECT name,
rootpage, sql FROM 'main'.sqlite_master", xCallback=0xa00590a8
<sqlite3InitCallback>, pArg=0xa02527c4, pzErrMsg=0x0) (SQLite\legacy.c:71)
#9 A0059A80 sqlite3InitOne(db=0xa025b858, iDb=0, pzErrMsg=0xa0269178)
(SQLite\prepare.c:329)
#10 A0059C98 sqlite3Init(db=0xa025b858, pzErrMsg=0xa0269178)
(SQLite\prepare.c:396)
#11 A0059E08 sqlite3ReadSchema(pParse=0xa0269170) (SQLite\prepare.c:433)
#12 A001B7E8 sqlite3LocateTable(pParse=0xa0269170, isView=0,
zName=0xa0268f58 "user", zDbase=0x0) (SQLite\build.c:296)
#13 A0070E9C selectExpander(pWalker=0xa0252968, p=0xa0268ef0)
(SQLite\select.c:3056)
#14 A009AABC sqlite3WalkSelect(pWalker=0xa0252968, p=0xa0268ef0)
(SQLite\walker.c:131)
#15 A0071868 sqlite3SelectExpand(pParse=0xa0269170, pSelect=0xa0268ef0)
(SQLite\select.c:3252)
#16 A0071B18 sqlite3SelectPrep(pParse=0xa0269170, p=0xa0268ef0,
pOuterNC=0x0) (SQLite\select.c:3335)
#17 A0072364 sqlite3Select(pParse=0xa0269170, p=0xa0268ef0,
pDest=0xa0252b78) (SQLite\select.c:3547)
#18 A0050780 yy_reduce(yypParser=0xa0269380, yyruleno=111) (parse.y:399)
#19 A00532AC sqlite3Parser(yyp=0xa0269380, yymajor=1, yyminor={z =
0xa01a894a "user", n = 4}, pParse=0xa0269170) (parse.c:3691)
#20 A0075AE8 sqlite3RunParser(pParse=0xa0269170, zSql=0xa01a893c "select *
from user", pzErrMsg=0xa0252ccc) (SQLite\tokenize.c:471)
#21 A005A378 sqlite3Prepare(db=0xa025b858, zSql=0xa01a893c "select * from
user", nBytes=-1, saveSqlFlag=0, ppStmt=0xa0252d78, pzTail=0xa0252d7c)
(SQLite\prepare.c:612)
#22 A005A78C sqlite3LockAndPrepare(db=0xa025b858, zSql=0xa01a893c "select *
from user", nBytes=-1, saveSqlFlag=0, ppStmt=0xa0252d78, pzTail=0xa0252d7c)
(SQLite\prepare.c:702)
#23 A005A9C4 sqlite3_prepare(db=0xa025b858, zSql=0xa01a893c "select * from
user", nBytes=-1, ppStmt=0xa0252d78, pzTail=0xa0252d7c)
(SQLite\prepare.c:765)
#24 A003BF98 sqlite3_exec(db=0xa025b858, zSql=0xa01a893c "select * from
user", xCallback=0xa003fcd0 <callback>, pArg=0x0, pzErrMsg=0xa0252dbc)
(SQLite\legacy.c:55)
#25 A003FE44 sqtest() (SQLite\main_test.c:27)
Dan Kennedy-4 wrote:
>
>
> On Sep 11, 2009, at 1:58 PM, gprand wrote:
>
>>
>> Hi Richard,
>>
>> First, thanks for replying to my problem.
>>
>> Definitely answer to your assumptions ist no. I can see the correct
>> sql
>> statement into the debugger, nothing is malformed. Checking
>> sizeof(char)
>> delivers 1. Processing the first 100 bytes does'nt produce error.
>> Much more,
>> processing of sqlite3_exec cause the error.
>> It looks to me, that something goes wrong when sqlite creates its
>> internal
>> mastertable. May be, the error message belongs to this table, not to
>> the
>> database file? Unfortunately, the debugger is spoofed in some
>> conditions, he
>> cannot trace the tokenizer and I do not look through enough.
>
> Here is something to try:
>
> Compile the library with SQLITE_DEBUG defined. Then before running the
> test,
> put a breakpoint in each of sqlite3Corrupt() and corruptSchema()
> functions.
> See which one it hits and post the stack trace.
>
> Dan.
>
>
>
>> Regards,
>>
>> Gottfried
>>
>>
>> D. Richard Hipp wrote:
>>>
>>>
>>> On Sep 10, 2009, at 2:23 AM, gprand wrote:
>>>> Program's output is:
>>>> OPENX 16 /database_file.db 01002
>>>> OPEN 16 /database_file.db
>>>> READ 16 100 0 0
>>>> SQL error: database disk image is malformed
>>>
>>> This indicates that SQLite is reading the first 100 bytes of the
>>> database file (the database file header) and is either unable to read
>>> those 100 bytes or after looking at those bytes determines that the
>>> database file is malformed.
>>>
>>> Possible causes: (1) your file I/O subsystem is doing some kind of
>>> \n
>>> to \r\n translation. (2) when you copied the database file onto the
>>> device, your copy utility corrupted the database file (again,
>>> possibly
>>> by \r to \r\n translation) (3) your compiler somehow thinks that
>>> sizeof(char)!=1.
>>>
>>> There might be other causes, but those are the ones that come to
>>> mind.
>>>
>>>> CLOSE 16
>>>
>>> D. Richard Hipp
>>> [email protected]
>>>
>>>
>>>
>>> _______________________________________________
>>> sqlite-users mailing list
>>> [email protected]
>>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/sqlite3_exec-fails-on-arm-tp25293839p25396004.html
>> Sent from the SQLite mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> sqlite-users mailing list
>> [email protected]
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
> _______________________________________________
> sqlite-users mailing list
> [email protected]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>
--
View this message in context:
http://www.nabble.com/sqlite3_exec-fails-on-arm-tp25293839p25397885.html
Sent from the SQLite mailing list archive at Nabble.com.
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
