SQLite Forum

NULL pointer access in sqlite3MemdbInit
Login

NULL pointer access in sqlite3MemdbInit

(1) By kjarvel on 2021-04-12 14:04:56 [source]

I'm building the sqlite3.c amalgamation version 3.35.4, for an embedded system without an OS, with these defines:

  • SQLITE_OS_OTHER
  • SQLITE_ENABLE_DESERIALIZE

The problem can be reproduced with with Visual C++ in Windows.

The build is OK, but at sqlite3_open(":memory:", &db), there is a NULL pointer access in sqlite3MemdbInit:

SQLITE_PRIVATE int sqlite3MemdbInit(void){
  sqlite3_vfs *pLower = sqlite3_vfs_find(0);
  int sz = pLower->szOsFile;

Since sqlite3_vfs_register has not been called at this point, pLower is NULL, and pLower->szOsFile is not valid. (sqlite3_vfs_register(&memdb_vfs,0) is called a few lines later).

Suggested change, to handle the NULL pointer:

 int sz = pLower ? pLower->szOsFile : 0;

A similar problem is in memdbRandomness:

static int memdbRandomness(sqlite3_vfs *pVfs, int nByte, char *zBufOut){
  return ORIGVFS(pVfs)->xRandomness(ORIGVFS(pVfs), nByte, zBufOut);

ORIGVFS(pVfs) is the pAppData pointer in memdb_vfs, which is 0x0. Suggested change, to handle the NULL pointer:

return ORIGVFS(pVfs) ? ORIGVFS(pVfs)->xRandomness(ORIGVFS(pVfs), nByte, zBufOut) : 0;

After this, it works fine.

Sorry if I misunderstood or mis-used sqlite3.c in some way, maybe there is another/real solution? Thank you!

(2) By David Boden (davidboden) on 2023-01-01 16:35:17 in reply to 1 [link] [source]

Happy New Year. I notice that this issue has also been mentioned in post: https://sqlite.org/forum/forumpost/48d46020bbbe5703a4805383e8d459ee6e689a73a5f7272ad9c2266b0c1eba10

I'm new to embedded programming and using SQLite in that environment. It would be great if we could build SQLite with SQLITE_OS_OTHER and then open up a ":memory:" database without having to worry about setting up a VFS at all. I think it would make a good test case, which would currently fail due to the issues you've mentioned if no steps have been taken to register a VFS.

Perhaps there are some additional tasks carried out by the VFS, such as finding a source of randomness, that means there's a need for a VFS even for in-memory databases? Would appreciate some feedback from an experienced SQLite developer as to whether it's realistic to expect creating in-memory databases to be easy within SQLITE_OS_OTHER builds.

(3) By Stephan Beal (stephan) on 2023-01-01 16:52:44 in reply to 2 [link] [source]

Would appreciate some feedback from an experienced SQLite developer as to whether it's realistic to expect creating in-memory databases to be easy within SQLITE_OS_OTHER builds.

The short answer is no. The memdb VFS inherits functionality from whichever VFS is built in as the default, so requires another VFS to be built in.