database/sqlite
1
0
Fork 0
mirror of https://github.com/sqlite/sqlite.git synced 2025-11-11 01:42:22 +03:00
Code Activity

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

Browse Source 
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
This commit is contained in:
drh
2018-10-11 13:51:48 +00:00
parent 1dbb147598
commit f7f2a82aa0
3 changed files with 13 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
src/os_unix.c
View File

@@ -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);
}
}