SQLite Forum

Hi all,

I've recently upgraded from 3.35.0 to 3.37.2, and stumbled on a minor thing in dropCell(), which pops up when SQLITE_DEBUG is enabled.

dropCell contains this line:

assert( pPage->pBt->usableSize > (int)(ptr-data) );

There's a comparison between signed (int) and unsigned (u32) values here, and I'm getting a compiler error from it. This is the only place I get this error in sqlite3.c so I'm disabling the warning for now.

Can this be corrected?

In the amalgamation file sqlite3.c, when compiled on Windows, SQLITE_OS_WIN is defined on line 16426 (in 3.35.0). But it's referenced earlier on line 13896 and again on 13912.

#if defined(SQLITE_FORCE_OS_TRACE) || defined(SQLITE_TEST) || \
    (defined(SQLITE_DEBUG) && SQLITE_OS_WIN)
  extern int sqlite3OSTrace;
# define OSTRACE(X)          if( sqlite3OSTrace ) sqlite3DebugPrintf X
# define SQLITE_HAVE_OS_TRACE
#else
# define OSTRACE(X)
# undef  SQLITE_HAVE_OS_TRACE
#endif

On Windows, this should enable OSTRACE if SQLITE_DEBUG is defined as a compiler option, but it only works if SQLITE_OS_WIN is explicitly defined too.

I thought SQLITE_OS_WIN is not supposed to be defined as a compiler option, as sqlite3.c does it on Windows if SQLITE_OS_OTHER is not defined.

Is there an error here?

For my test I was building a unit test around some of my code that is using SQLite using CppUTest, so it's a DEBUG WIN32 console application compiled using Visual Studio.

The checked heap is CppUTest's one. I believe it replaces malloc() and free() with its own wrappers to add instrumentation and guards, but it isn't replacing msize() as well, so I assume SQLite is seeing the size of the underlying allocation including the CppUTest guards.

I'm now using -DDSQLITE_WITHOUT_MSIZE. This also makes things closer to how it'll behave on the embedded platform I'll eventually be using.

OK I think I might have found the reason. After allocating memory, SQLite is ultimately calling _msize() to get the actual amount of allocated memory, but the size returned includes the guards added by the checked heap, and it's those that later get overwritten.

Sorry for wasting your time.

I'm not using sqlite.exe but compiling the amalgamation version of sqlite3.c into my code. The overrun is being detected by a checked heap.

I've reduced the number of SQL statements to just two:

CREATE TABLE aaaaaa (bbb_id TEXT,ccccccc_id TEXT,ddd TEXT);
CREATE INDEX aaaaaa_ccccccc_id ON aaaaaa (bbb_id ASC,ccccccc_id ASC);

If it helps, at some point sqlite3StrAccumEnlarge() gets called with N=8. The string at this point is 0x44 bytes long "INSERT INTO 'main'.sqlite_master VALUES('index','aaaaaa_ccccccc_id',". sqlite3DbRealloc() then gets called with p->nAlloc = 0x91.

It's that allocation that gets rounded up to 0x98 and then overrun by 1 byte. I haven't been able to follow what's happening to see why yet.

Mark

I'm trying to develop a new application using SQLite 3.32.2 on Windows. During startup, the code is creating a database with 7 tables and indexes. When one of those indexes is being created, I'm seeing a buffer overrun on some memory allocated by SQLite.

It's happening in a buffer allocated to build the "INSERT INTO 'main'.sqlite_master..." statement. Looking at the call stack, sqlite3Malloc() is being called to allocate 0x91 bytes, that gets rounded up to 0x98 bytes before malloc() is called, but then 0x99 bytes are written to that buffer (the 0x99'th byte is the NULL terminator). When the buffer is eventually freed, the memory manager is detecting the overrun.

I'm a bit stumped on how to correct this. I've probably done something wrong somewhere but I'm only creating tables and indexes so far. I have found that if I just shorten or lengthen the name of the index, the overrun doesn't occur. And it's only happening on one of the indexes.

Any ideas?