Thanks for your reply. I repeated the experiment by setting db->mallocFailed upon return. You are right that there is no segmentation fault (there were some assertion failures: e.g, "sqlite3OomClear: Assertion `db->lookaside.bDisable>0' failed"). Instead I got error messages saying out of memory. It makes sense now. May I ask where the unwinding is done? Does it mean the program stops execution at sqlite3SrcListAppend()?
Shaobo Richard Hipp <d...@sqlite.org>于2017年2月1日周三 下午5:28写道： > On 2/1/17, Shaobo He <polarish...@gmail.com> wrote: > > > > Basically, the error trace indicate that `sqlite3SrcListAppend` can > return > > a null pointer under the presence of OOM and this return value can > > propagate to somewhere in the program, resulting in a null pointer > > deference. > > An OOM condition inside of sqlite3SrcListAppend() will set the > db->mallocFailed flag, which will cause the stack to unwind, and > thereby prevent NULL pointer dereferences. > > Please repeat your experiment by forcing sqlite3SrcListAppend() to > return NULL but at the same time set db->mallocFailed. If you > continue hit a segfault, that is an issue. But I'm guessing you will > not. > > We do a lot of OOM testing in SQLite. See > https://www.sqlite.org/testing.html#oomtesting for a summary of the > technique. There are 829 OOM test loops in TH3 and more in the TCL > test suite. We do, rarely, find OOM problems in release builds, but > because of our OOM testing procedures such findings are quite rare. > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
