Didn't mean to imply that failing to check the return value resulted in memory corruption. I was wondering if it was possible that one of the many calls to sqlite3_bind_* in my code may actually be causing some memory corruption. I can envision some possible buffer overflows associated with those calls.
None of the crashes are reproducible at all. I have personally never seen one of the crashes. I get one or two reports a week from my user base. This is what makes this such a pain. As we all know, it's very hard to diagnose a problem we can't replicate. Rick On Jul 19, 2012, at 12:00 PM, Richard Hipp wrote: > 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? _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
