Thanks for the help. I took a little while to extract our standard out ( It's multiplexed with the test harness results at current ).
Here's the trace:- VDBE Execution Trace: SQL: [PRAGMA vdbe_trace=ON] 0 Expire 1 0 1 Halt 0 0 VDBE Execution Trace: SQL: [SELECT * FROM sqlite_master] 0 Goto 0 14 14 Transaction 0 0 15 VerifyCookie 0 1 16 Goto 0 1 1 Integer 0 0 # sqlite_master Stack: i:619574286855700480 2 OpenRead 0 1 3 SetNumColumns 0 5 4 Rewind 0 12 5 Column 0 0 # sqlite_master.type Stack: s5[table](8) 6 Column 0 1 # sqlite_master.name Stack: s7[Players](8) s5[table](8) 7 Column 0 2 # sqlite_master.tbl_name Stack: s7[Players](8) s7[Players](8) s5[table](8) 8 Column 0 3 # sqlite_master.rootpage Stack: i:0 s7[Players](8) s7[Players](8) s5[table](8) 9 Column 0 4 # sqlite_master.sql Stack: z52[CREATE TABLE Pl](8) i:0 s7[Players](8) s7[Players](8) s5[table](8) 10 Callback 5 0 11 Next 0 5 12 Close 0 0 13 Halt 0 0 VDBE Execution Trace: SQL: [INSERT INTO Players VALUES ( "Joe","Cole")] 0 Goto 0 11 11 Transaction 0 1 12 VerifyCookie 0 1 13 Goto 0 1 1 Integer 0 0 # Players Stack: i:0 2 OpenWrite 0 2147483647 I don't really know what any of it means, but I was curious with the Stack: i:619574286855700480. This is a co-ercion to 64 bit long of a location in our application's execution stack. ( 0x8992B88 ). Is this supposed to be the case? In the meantime, I guess I'd better read up on what all of this stuff means..... Many Thanks, Richard -- Richard Barrass. Senior Embedded Software Engineer Cardinal Health (Alaris Products). e: [EMAIL PROTECTED] t: 01256 388381 f: 01256 388466 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 14 August 2006 15:32 To: sqlite-users@sqlite.org Subject: Re: [sqlite] Problems with sqlite 3.3.6 on ARM embedded platform "Barrass, Richard" <[EMAIL PROTECTED]> wrote: > > The breakpoint was hit twice during execution of this test ( once from > the CREATE TABLE Players query, once from the SELECT * from > sqlite_master query ). On both occasions, pMem->i appeared to be > correctly assigned the value 2. > The next thing to try is to single-step the code forward from this breakpoint until the value of pMem->i changes from 2 to 0x200000002. A faster way to find out where the faulty conversion is occurring is to compile with -DSQLITE_DEBUG=1 and set "PRAGMA vdbe_trace=ON". This will trace the execution of the SQLite virtual machine show values on the stack after each operation. Perhaps that will show us where the 0x200000002 is first appearing. -- D. Richard Hipp <[EMAIL PROTECTED]> ------------------------------------------------------------------------ ----- 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. Danish - Deutsch - English - Espanol - Francais - Italiano - Japanese - Nederlands - Norsk - Portuguese - Svenska: www.cardinalhealth.com/legal/email ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
