Hi all, Further information to the original post below is that:
1) The application is single user, single threaded. 2) I have retested using :memory:, rather than my test database file. For this test, I created a database 'on the fly'. Again, the PC host seems to have no problems, but the ARM displays the same problems ( SELECT * from any table other than sqlite_master fails. SELECT * from sqlite_master seems to show corrupted root table entries. ) 3) The only SQLite build options I'm using is -DOS_OTHER ( everything else is per 'out of box' ). 4) I've now tried both V3.3.6 and V3.3.7 with the same results. The curious thing I've noticed is that the corruptions below seem to be 64 bit values. It looks like something different is happening on our ARM to the PC. The only *obvious* difference I've spotted so far is the sign of char (the ARM has unsigned , PC signed). I tried rebuilding with -fsigned-char, but unfortunately, something elsewhere stopped working (someone checking ret >= 0, no doubt!). Any help would be really appreciated. Richard -- Richard Barrass. Senior Embedded Software Engineer Cardinal Health (Alaris Products). e: [EMAIL PROTECTED] t: 01256 388381 f: 01256 388466 -----Original Message----- From: Barrass, Richard Sent: 11 August 2006 19:58 To: [email protected] Subject: [sqlite] Problems with sqlite 3.3.6 on ARM embedded platform Hello We have the source code of SQlite 3.3.6 working in the following configuration: mingw-win32 compiler (GCC v3.4.2). Our test application works fine with our small (~22k) test database. However, on our embedded platform (ARM 9) with the following configuration Code-sourcey arm-none-eabi cross compiler (GCC v3.4.4) running with newlib. we have errors reading the database. We can read the sqlite_master table, but as soon as we try and read anything else, we get an error 11 (malformed database). Detailed inspection of the file IO shows this to be binary equivalent on both platforms, but when reading the 'root page column' from sqlite_master table, the number seen as table '2' on the working platform, became 8589934594 (or in Hex, 0x200000002) A similar corruption was seen for the other tables - table 3 -> 0x300000003, table 4 ->0x400000004. Has anyone seen this before - help! - what should we try next? Many thanks to anybody who can help. Richard -- Richard Barrass. Senior Embedded Software Engineer Cardinal Health (Alaris Products). e: [EMAIL PROTECTED] t: 01256 388381 f: 01256 388466 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] -----------------------------------------------------------------------------
