On 1/31/17, Shaobo He <polarish...@gmail.com> wrote: > Hi there, > > My name is Shaobo He and I am a graduate student at University of Utah. I > am applying a couple of static analysis tools to C projects. The tools I am > using reports a few partial error traces about null pointer dereferences. I > was wondering if you could help me to identify whether they (described > below) were true bugs or just false positives. Your feedback is really > appreciated.
They are both false-positives. > > 1) In function `statGet`, `sqlite3_value_blob` can return a null pointer. > One possible case is that `ExpandBlob(p)` returns `SQLITE_OK` and the > condition expression `p->n ? p->z : 0;` evaluates to null given `p->n == > 0`. I tried to figure out if `p->n` can be 0 by adding an assertion before > the call site to `sqlite_value_blob` and running all regression tests. It > seems it cannot be for these test cases. My question is that if the case > described above can happen. Moreover, function `statPush` has a similar > error trace. The first parameter to statGet() and statPush() will always be a sizeof(void*)-byte blob that is in fact a pointer to an object. So sqlite3_value_blob() will never return NULL there. > > 2) In function `walCleanupHash`, `aHash` is initialized to null and is > probably updated by function `walHashGet`. However, the update may not > happen if `walIndexPage` returns a status not equal to `SQLITE_OK`. So > `aHash` remains null and got dereferenced. In walCleanupHash(), the pages of the -shm file that contains the hash have already been allocated and initialized - otherwise walCleanupHash() would have never been called. But if the -shm file has already been allocated and initialized, then there is no way for walHashGet() to fail and leave aHash uninitialized. -- 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
