On 12-04-04 11:20 AM, Richard Hipp wrote:
2012/4/4 Rafael Ávila de Espíndola<respind...@mozilla.com>
Currently if the call
p->zSql = sqlite3DbStrNDup(p->db, z, n);
fails, zSql will stay null without the caller being notified that it
failed. sqlite3VdbeSetSql should probably return a bool. With that,
sqlite3Prepare could check it and return SQLITE_NOMEM.
When sqlite3DbStrNDup() fails, it sets the mallocFailed flag in p->db.
This later gets translated into an SQLITE_NOMEM error which is returned by
sqlite3_prepare().
We have test cases for this very occurrence.
Awesome!
In fact, during out-of-memory (OOM)
testing<http://www.sqlite.org/testing.html#oomtesting>,
our test harnesses verify that every simulated OOM error does in fact
result in an SQLITE_NOMEM error (or at least some kind of error). There
are a few places in the code where a memory allocation is merely an
optimization and is not required for correctness. (For example
here<http://www.sqlite.org/src/artifact/458488dcc159c30?ln=114-120>.)
In those places, a failed allocation does not result in an error. But
those cases are surrounded by calls to sqlite3BeginBenignMalloc() and
sqlite3EndBenignMalloc(), which disable the logic in the test harnesses
that verify that all OOM errors are detected. The allocation of the zSql
string is not one of those places, however. I have just now double-checked
that it is not by running one of our test programs in a debugger.
Thanks for checking this. Sorry I missed the check in sqlite3ApiExit.
I thought this was the root problem in
https://bugzilla.mozilla.org/show_bug.cgi?id=741821, where we are
accessing a null returned by sqlite3_sql, but I guess it is mozilla's
code that is eating the error somewhere.
Thanks,
Rafael
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
