On Thu, Jul 19, 2012 at 1:56 PM, Rick Maddy <rma...@gmail.com> wrote:
> What about checking all the sqlite3_bind_* methods? Is it possible any of > those could cause the problems I'm seeing? > Being busing with other issues, I have not been following this thread closely, so perhaps I have missed something, but.... Failure to check a return code from an SQLite API is not going to cause memory corruption. Memory corruption usually comes about when some other subsystem in the application frees memory but continues to use it, then SQLite allocates that memory and expects to have the memory to itself but the other subsystem is still using too. The usual technique for finding that kind of problem is to run the application in valgrind. But I guess that isn't really an option for you.... Is the problem reproducible for you in your lab at all? > > Rick > > > > On Jul 19, 2012, at 11:42 AM, Simon Slavin wrote: > > > > > On 19 Jul 2012, at 6:03pm, Rick Maddy <rma...@gmail.com> wrote: > > > >> Thanks. Time to add checks to nearly 400 prepare and step statements. > > > > Sorry about that. But you should be able to make a tiny test function > which just tests the result and makes sure it's SQLITE_OK. > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
