Hi, List To make it easy to review, I've make the test code as an single c file and removed some unrelated code from the previous version. Could you so kind to point out potential problems in it, or tell me what else things I could get to check in the code or in my environment.
https://www.dropbox.com/s/y6rtajv2j9burag/sqlitecs.c Even more directly, could anyone can build from this source an arm eabi binary and send to me? Also should includes the libsqlite so files. If I can run it without a problem, then it's a compiler problem. Thanks in advance. On Thursday, 2 January 2014, Yuriy Kaminskiy wrote: > Woody Wu wrote: > > Hi, Simon > > > > I upload the source code onto my dropbox: > > https://www.dropbox.com/s/9shhshi0wn3e717/downloadfile.c Please have a > > look at it. > > > > The same test program run without a problem on my pc Linux after complied > > natively. But I think I should not dout my cross-compiler, which is > > CodeBench ARM eabi compiler. With the same complier and the toolchain, I > > have been buit a whole target ARM system including kernel, 1000 open > source > > applications, even including a tiny X window. > > Well, compiler bugs are sometimes very rarely triggered, and by completely > innocent code, so I would not exclude this possibility. > FWIW, I don't see anything obviously broken/sigsegv-worthy in above test > program > [assuming missing headers contained something like > > int sql_exec_v2(sqlite3 *conn, const char *sql) { > // note: sql_exec_v2 expected to return SQLITE_DONE on success > // sqlite3_exec returns SQLITE_OK on success > int sqlerr, ret; > sqlite3_stmt *stmt; > sqlerr = sqlite3_prepare_v2(conn, sql, -1, &stmt, NULL); > if (sqlerr != SQLITE_OK) return sqlerr; > ret = sqlite3_step(stmt); > sqlerr = sqlite3_finalize(stmt); > if (sqlerr != SQLITE_OK) return sqlerr; > return ret; > } > int timespec_diff_ms(const struct timespec *ts1, const struct timespec > *ts2) { > return (ts2->tv_sec - ts1->tv_sec)*1000 + > (ts2->tv_nsec-ts1->tv_nsec)/1000000; > } > #define inst_signal_handler(SIGNAL,HNDL,FOO) signal((SIGNAL),(HNDL)) > > ], but as this is "impossible error" it would make sense to add error > checking > for *everything*, including "impossible errors". > > > On Tuesday, 31 December 2013, Simon Slavin wrote: > > > >> On 31 Dec 2013, at 8:41am, Woody Wu > >> <narkewo...@gmail.com<javascript:;><javascript:;>> > >> wrote: > >> > >>> Attached is the test program writting in C. > >> Sorry, but attachments don't work here. If your program is short, > please > >> post it as text. If not, please put it on a web site somewhere. > >> > >>> Anyway, all above errors looks so strange. And, these operations I > >> talking > >>> about are so basic and my real application (another bigger one) really > >>> depends on these. > >> You should not be able to make SQLite corrupt its database that easily. > >> > >>> Pleaes be kindly to check my test program. > >> Can you run your program on the computer you used to send that email > >> message and tell us whether it had the same problem ? > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org <javascript:;> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- Life is the only flaw in an otherwise perfect nonexistence -- Schopenhauer narke public key at http://subkeys.pgp.net:11371 (narkewo...@gmail.com) _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
