Hi,
When you ported sqlite to your os-less ARM based platform, did you do any other
changes to the sqlite source code?
I'm facing new problems right now. the record cann't be inserted correctly when
I execute the following statements.
......
char * database = ":memory:";
sqlite3 * db;
sqlite3_open(database, &db);
sqlite3_exec(db, "create table myt(name varchar(30),age smallint)", NULL,
NULL, NULL);
sqlite3_exec(db, "insert into myt values('sarah',27)", NULL, NULL, NULL);
sqlite3_exec(db, "select * from myt", NULL, NULL, NULL);
sqlite3_close(db);
......
The behavior is that , when executing "insert into myt values('sarah',27)",
the program goes into the following statements in sqlite3RunParser() and
returns
SQLITE_NOMEM. How and why?
......
abort_parse:
if( zSql[i]==0 && nErr==0 && pParse->rc==SQLITE_OK ){
if( lastTokenParsed!=TK_SEMI ){
sqlite3Parser(pEngine, TK_SEMI, pParse->sLastToken, pParse);
pParse->zTail = &zSql[i];
}
sqlite3Parser(pEngine, 0, pParse->sLastToken, pParse);
}
sqlite3ParserFree(pEngine, sqlite3FreeX);
if( sqlite3MallocFailed() ){
pParse->rc = SQLITE_NOMEM;
}
......
I totally have no idea of the principals of parser and how it works. Could
someone tell me or give me some links?
finally, a stupid question:
should I add a semicolon at the end of the sql statement in sqlite3_exec();
Will that affect the execution of parser?
a lot of thanks!
----- Original Message -----
From: "Barrass, Richard" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, September 12, 2006 7:41 PM
Subject: RE: [sqlite] met "ARM7TDMI raised an exception,data abort" when
executing sqlite3Parser() in ARM environment
Hi
We have sqlite (v3.3.7) running on an os-less ARM based platform - we
use MINGW cross compilers (GCC3.4.4) - from CodeSourcery.
There was an issue earlier on that seems to be an issue with 64 bit
support - we switched off the 64bit support in the compilation of the
sqlite library and this for now has got the data base up and running on
our platform.
Richard
-----Original Message-----
From: Nuno Lucas [mailto:[EMAIL PROTECTED]
Sent: 11 September 2006 21:12
To: [email protected]
Subject: Re: [sqlite] met "ARM7TDMI raised an exception,data abort" when
executing sqlite3Parser() in ARM environment
[forgot to reply to the list]
---------- Forwarded message ----------
From: Nuno Lucas <[EMAIL PROTECTED]>
Date: Sep 11, 2006 9:07 PM
Subject: Re: Re: [sqlite] met "ARM7TDMI raised an exception,data abort"
when executing sqlite3Parser() in ARM environment
To: [EMAIL PROTECTED]
On 9/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I don't think NULL callback and error pointer will be the reason.
> Because I've seen this kind of usage in the list for several times.
As I said earlier, I don't think this is the reason also. Just one more
thing you could check.
> Anyway, I'll try later and report the result to the list.
>
> If it is a misaligned-pointer problem, what can I do?
>
> I don't make any change to the sqlite source code, how should this
> happen? I can run it correctly on PC(windows XP), why can't in an
> embedded environment? I'm confused...
You are aware they are completely different architectures, don't you?
You also didn't specify what OS you are running, which could make it
easier to get help from other experienced programmers for your platform
(if you are using CodeWarrior I would guess it's not Windows CE).
A misaligned-pointer can never occur on Windows (desktop editions, not
Windows CE), because Windows only runs on the Intel x86 processor
family, which mask that kind of things from you (although you usually
have a performance hit).
Basically it means you are accessing memory that is not aligned to the
minimum granularity the processor supports (which depends on the
processor and processor mode, but usually is 32 bits - 4 bytes - for
32-bits cpus, 64 bits - 8 bytes - for 64-bits cpus, etc).
I don't know if that is your case, but I have seen it before on Windows
CE (using a StrongArm processor) and because there aren't so many people
using SQLite with those processors, the code path is not so much tested
as the x86 case (which doesn't trigger a cpu exception, only a
performance hit).
It's up to you to confirm this is the case, but there are other things
which can be wrong, like little/big endian problems, compiler bugs
(recent platforms don't have so much testing as older ones), bad
compiler/linker options, stack overflows (because in embedded systems
you usually have a much lower default stack size), etc.
Without more info that's all I can say.
Regards,
~Nuno Lucas
------------------------------------------------------------------------
-----
To unsubscribe, send email to [EMAIL PROTECTED]
------------------------------------------------------------------------
-----
_________________________________________________
This message is for the designated recipient only and may contain privileged,
proprietary, or otherwise private information. If you have received it in
error, please notify the sender immediately and delete the original. Any other
use of the email by you is prohibited.
Dansk - Deutsch - Espanol - Francais - Italiano - Japanese - Nederlands - Norsk
- Portuguese - Svenska: www.cardinalhealth.com/legal/email
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
