On the first connection to a WAL-mode database that was not cleanly shut down

and contains a left-over -shm file, truncate the -shm file to 3 bytes instead
of to 0 bytes. Avoiding a truncation to 0 means that system monitoring tools
can better detect if a process illegitimately tries to truncate a -shm file.
Such a rogue process might think it is being helpful by cleaning up old files,
but there is a race condition that can cause damage to the database.

FossilOrigin-Name: 90cf32cde072a305f30c75a71665d1f9e23e805c0a49f5306f015c056dd70f0c

1 files changed, 6 insertions, 1 deletions

diff --git a/src/os_unix.c b/src/os_unix.c
index 4228aaaf0..f20763e5b 100644
--- a/src/os_unix.c
+++ b/src/os_unix.c
@@ -4435,7 +4435,12 @@ static int unixLockSharedMemory(unixFile *pDbFd, unixShmNode *pShmNode){
       rc = SQLITE_READONLY_CANTINIT;
     }else{
       rc = unixShmSystemLock(pDbFd, F_WRLCK, UNIX_SHM_DMS, 1);
-      if( rc==SQLITE_OK && robust_ftruncate(pShmNode->hShm, 0) ){
+      /* The first connection to attach must truncate the -shm file.  We
+      ** truncate to 3 bytes (an arbitrary small number, less than the
+      ** -shm header size) rather than 0 as a system debugging aid, to
+      ** help detect if a -shm file truncation is legitimate or is the work
+      ** or a rogue process. */
+      if( rc==SQLITE_OK && robust_ftruncate(pShmNode->hShm, 3) ){
         rc = unixLogError(SQLITE_IOERR_SHMOPEN,"ftruncate",pShmNode->zFilename);
       }
     }