On Mon, Nov 14, 2016 at 10:51 PM, James K. Lowden <jklow...@schemamania.org> wrote:
> On Mon, 14 Nov 2016 20:30:57 -0500 > "pisymbol ." <pisym...@gmail.com> wrote: > > > One last thing: This is during initialization and I access the > > database through that query several times before hitting this crash. > > > > I thought it was memory corruption but it always the same line. > > Trying to be helpful, even if it doesn't sound like it: That doesn't > exonerate your code! > > Presumably you do something with the results of those several queries. > Probably what you do is highly deterministic, maybe identical, run upon > run. Likely is you're just corrupting memory in the same way each > time. Not corrupting as in "writing to random memory", but as in > "writing in a determistic way to memory you don't mean to". That the > error is repeatable suggests it's not related to a race condition, but > where threading is concerned that's never a culprit to be dismissed. > > I would run your code under valgrind first. If that doesn't find > anything, trap the segfault in gdb and find the basis for it, even if > it's deep in the parser. Some offset/pointer is wrong. Find out what > it is, and set a watchpoint on it. If it's as determistic as you say, > I'll lay odds gdb will stop at a *very* surprising place, in your > code. > > I totally agree and this is EXACTLY what I did.Thank you! I found the bug. Sigh. A thread was calling sqlite3_free() instead of sqlite3_finalize() on a prepared statement which was causing an issue. Anyway, thanks to everyone who gave me tips. Some days.... -aps _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
