From the evidence you have shown and mentioned, it is premature to conclude or declare that the crash is due to "a SQLite bug". There certainly won't be a workaround for an access fault occurring when a data structure used successfully in numerous other applications goes wrong because the pointer being dereferenced has been clobbered by as-yet mysterious previous code. Can you run the crash-inducing scenario under a debugger? This is a problem that probably reflects operation of a bug somewhere, but until it can be determined when, and by what, the pointer value picked up by "pLeft = pExpr->pLeft" has been made invalid, reliably avoiding it by query selection or adjustment is going to be difficult and prone to failure. Discovering what code improperly rewrote that value is a relatively simple task when a debugger can be used and the crash scenario and resulting crash are repeatable. You need to abandon the idea of "potentially dangerous queries". They are all dangerous when something is trashing random memory locations. Later amendment: After sifting through the OP's interactions in another forum on this problem, I was able to find the DB and query that exhibits the fault. That DB is where the schema in my below post came from. The crash requires no data as the failure occurs during the prepare. Given that the problem reproduces with the released sqlite3.exe shell (v3.31.1), and some known SQL, I now think it can be fairly called a SQLite bug. My advice, about abandoning the "dangerous queries" idea, stands.