I believe that is the cause! The SQLite documentation is kind of obscure when comes to concurrent usage. I've done a lot of experiments and just realize recently that I might just change the open flag from "SQLITE_OPEN_NOMUTEX" to "SQLITE_OPEN_FULLMUTEX". Today I did the change and re-compiled the program, no crash now. Citing the documentation of flag "[SQLITE_OPEN_NOMUTEX](https://www.sqlite.org/c3ref/open.html)": > The new database connection will use the "multi-thread" threading mode. This means that separate threads are allowed to use SQLite at the same time, as long as each thread is using a different database connection. I just remembered that "NOMUTEX" can be used to run SQLite in "multi-thread" mode (the names are really confusing). And the last sentence says "as long as each thread is using a different database connection", I don't think this means this: each thread should have its own exclusive connection. So it leads me to suppose as long as only one thread is using one connection at a time, it's OK. It turns out that if one connection is used by thread 1, after that, then it's used by thread 2, then there is problem. This can be observed from my experiment, I set the open read connection to 1, but with multiple threads using the same connection to do reading, although my application has mutex to synchronize the using of such connection, the crash would always happen. There is also a question on stackoverflow confirming this: https://stackoverflow.com/questions/10079552/what-do-the-mutex-and-cache-sqlite3-open-v2-flags-mean From the answer: > SQLITE_OPEN_NOMUTEX does compile (or active on sqlite3_open_v2), the usage of SQLite without internal mutex. Still safe to be use SQLite multithread **BUT in my experience work only safely with individual connection open in each thread. Do NOT try to share a connection between Thread with this mode**. I hope SQLite can be a little bit more verbose and precise on documentation and that could help prevent people from learning it the hard way...