From: drh <> Date: Fri, 1 May 2026 16:03:51 +0000 (+0000) Subject: Check-in [1786fcd5b4ee6cd9] works great and generates correct code, but it X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=a9c2e080879d8b0dfa8dc3b5ac94214042ded0a6;p=thirdparty%2Fsqlite.git Check-in [1786fcd5b4ee6cd9] works great and generates correct code, but it upset UBSAN. This check-in fixes the UBSAN complaint. FossilOrigin-Name: 7cd76847e8c9b683e39c1063a343288f11b4aa5e9302394fe0c4244d361ee4f1 --- diff --git a/manifest b/manifest index d512e24e52..cbfee00d44 100644 --- a/manifest +++ b/manifest @@ -1,5 +1,5 @@ -C The\svalue\sfor\s/f\sand\sother\sfilename\ssubstitutions\sin\sSQLITE_PS1\sis\snow\n"memory"\sif\sopen\son\san\sin-memory\sdatabase. -D 2026-04-30T18:23:58.352 +C Check-in\s[1786fcd5b4ee6cd9]\sworks\sgreat\sand\sgenerates\scorrect\scode,\sbut\sit\nupset\sUBSAN.\s\sThis\scheck-in\sfixes\sthe\sUBSAN\scomplaint. +D 2026-05-01T16:03:51.242 F .fossil-settings/binary-glob 61195414528fb3ea9693577e1980230d78a1f8b0a54c78cf1b9b24d0a409ed6a x F .fossil-settings/empty-dirs dbb81e8fc0401ac46a1491ab34a7f2c7c0452f2f06b54ebb845d024ca8283ef1 F .fossil-settings/ignore-glob 35175cdfcf539b2318cb04a9901442804be81cd677d8b889fcc9149c21f239ea @@ -712,8 +712,8 @@ F src/msvc.h 80b35f95d93bf996ccb3e498535255f2ef1118c78764719a7cd15ab4106ccac9 F src/mutex.c 00b8cee206a67fd764d001f3a148494331d8d0b3b9c3974ecd69ff29bb444462 F src/mutex.h a7b2293c48db5f27007c3bdb21d438873637d12658f5a0bf8ad025bb96803c4a F src/mutex_noop.c 9d4309c075ba9cc7249e19412d3d62f7f94839c4 -F src/mutex_unix.c 9dce885059f9d2bb226e6e03bb2b41af4b89d40c323f908b58f5d05ff0565884 -F src/mutex_w32.c ce7cae45dacae9897adee44db0264fb04d1a7c124ffa83a4308516ed088cbbad +F src/mutex_unix.c caec9862aeebad01f6c8997cf709a239abeb0715fcce1895720b87fe7e2ef42f +F src/mutex_w32.c d44e94c064f8ab39e0318fb6fa00171cf7e5645bd4241129b07d655a8ddbd44b F src/notify.c 57c2d1a2805d6dee32acd5d250d928ab94e02d76369ae057dee7d445fd64e878 F src/os.c 509452169d5ea739723e213b8e2481cf0e587f0e88579a912d200db5269f5f6d F src/os.h 1ff5ae51d339d0e30d8a9d814f4b8f8e448169304d83a7ed9db66a65732f3e63 @@ -2203,8 +2203,8 @@ F tool/warnings-clang.sh bbf6a1e685e534c92ec2bfba5b1745f34fb6f0bc2a362850723a9ee F tool/warnings.sh a554d13f6e5cf3760f041b87939e3d616ec6961859c3245e8ef701d1eafc2ca2 F tool/win/sqlite.vsix deb315d026cc8400325c5863eef847784a219a2f F tool/winmain.c 00c8fb88e365c9017db14c73d3c78af62194d9644feaf60e220ab0f411f3604c -P 6f7a5ff22db10f889596239aae5f6a1130cbdfe72612ceee68cbeb3b86e40227 -R b9180aa4015aee7301b72716ab286936 +P 4aac1057eeaf6c29a4893e9c080497c780b0963e810c501532d79eba1b457f27 +R 74200f0a0383f282cba5b1796713142c U drh -Z bb5bb7bf82d762c087c32274cee3c7d2 +Z 73b4b7a2467bd85e602423bc2cc89be8 # Remove this line to create a well-formed Fossil manifest. diff --git a/manifest.uuid b/manifest.uuid index bc4bc6f398..11b019dc28 100644 --- a/manifest.uuid +++ b/manifest.uuid @@ -1 +1 @@ -4aac1057eeaf6c29a4893e9c080497c780b0963e810c501532d79eba1b457f27 +7cd76847e8c9b683e39c1063a343288f11b4aa5e9302394fe0c4244d361ee4f1 diff --git a/src/mutex_unix.c b/src/mutex_unix.c index ab504cb6e3..d463690d1c 100644 --- a/src/mutex_unix.c +++ b/src/mutex_unix.c @@ -44,14 +44,8 @@ /* ** Each SQLite mutex is an instance of the following structure. ** -** The ALIGN128 macro attempts to force 128-byte alignment on mutexes, -** so that adjacent mutex objects are always on different cache lines -** in the CPU. This is CPU-dependent, of course, but 128-byte alignment -** seems to work well for all contemporary processors. Experiments show -** that 64 works just as well most of the time, but the internet says -** that 128-byte alignment works better. */ -struct ALIGN128 sqlite3_mutex { +struct sqlite3_mutex { pthread_mutex_t mutex; /* Mutex controlling the lock */ #if SQLITE_MUTEX_NREF || defined(SQLITE_ENABLE_API_ARMOR) int id; /* Mutex type */ @@ -164,19 +158,31 @@ static int pthreadMutexEnd(void){ return SQLITE_OK; } ** the same type number. */ static sqlite3_mutex *pthreadMutexAlloc(int iType){ - static sqlite3_mutex staticMutexes[] = { - SQLITE3_MUTEX_INITIALIZER(2), - SQLITE3_MUTEX_INITIALIZER(3), - SQLITE3_MUTEX_INITIALIZER(4), - SQLITE3_MUTEX_INITIALIZER(5), - SQLITE3_MUTEX_INITIALIZER(6), - SQLITE3_MUTEX_INITIALIZER(7), - SQLITE3_MUTEX_INITIALIZER(8), - SQLITE3_MUTEX_INITIALIZER(9), - SQLITE3_MUTEX_INITIALIZER(10), - SQLITE3_MUTEX_INITIALIZER(11), - SQLITE3_MUTEX_INITIALIZER(12), - SQLITE3_MUTEX_INITIALIZER(13) + /* Static mutexes - those with IDs of 2 or more... + ** + ** The ALIGN128 macro attempts to force 128-byte alignment on mutexes, + ** so that adjacent mutex objects are always on different cache lines + ** in the CPU. This is CPU-dependent, of course, but 128-byte alignment + ** seems to work well for all contemporary processors. Experiments show + ** that 64 works just as well most of the time, but the internet says + ** that 128-byte alignment works better. + */ + static ALIGN128 union staticMutex { + sqlite3_mutex m; + char aSpacer[128]; + } aMutex[] = { + { .m = SQLITE3_MUTEX_INITIALIZER(2) }, + { .m = SQLITE3_MUTEX_INITIALIZER(3) }, + { .m = SQLITE3_MUTEX_INITIALIZER(4) }, + { .m = SQLITE3_MUTEX_INITIALIZER(5) }, + { .m = SQLITE3_MUTEX_INITIALIZER(6) }, + { .m = SQLITE3_MUTEX_INITIALIZER(7) }, + { .m = SQLITE3_MUTEX_INITIALIZER(8) }, + { .m = SQLITE3_MUTEX_INITIALIZER(9) }, + { .m = SQLITE3_MUTEX_INITIALIZER(10) }, + { .m = SQLITE3_MUTEX_INITIALIZER(11) }, + { .m = SQLITE3_MUTEX_INITIALIZER(12) }, + { .m = SQLITE3_MUTEX_INITIALIZER(13) }, }; sqlite3_mutex *p; switch( iType ){ @@ -213,12 +219,12 @@ static sqlite3_mutex *pthreadMutexAlloc(int iType){ } default: { #ifdef SQLITE_ENABLE_API_ARMOR - if( iType-2<0 || iType-2>=ArraySize(staticMutexes) ){ + if( iType-2<0 || iType-2>=ArraySize(aMutex) ){ (void)SQLITE_MISUSE_BKPT; return 0; } #endif - p = &staticMutexes[iType-2]; + p = &aMutex[iType-2].m; break; } } diff --git a/src/mutex_w32.c b/src/mutex_w32.c index bb2660f57d..ee54e39dbf 100644 --- a/src/mutex_w32.c +++ b/src/mutex_w32.c @@ -49,7 +49,7 @@ ** that 64 works just as well most of the time, but the internet says ** that 128-byte alignment works better. */ -struct ALIGN128 sqlite3_mutex { +struct sqlite3_mutex { union { CRITICAL_SECTION cs; /* The CRITICAL_SECTION mutex. id==1 */ SRWLOCK srwl; /* The Slim reader/writer lock. id!=1 */ @@ -95,9 +95,19 @@ void sqlite3MemoryBarrier(void){ } /* -** Initialize and deinitialize the mutex subsystem. +** Static mutexes. +** +** The ALIGN128 macro on the static mutex array forces 128-byte alignment +** on the mutexes so that adjacent mutex objects are always on different +** cache lines in the CPU. This is CPU-dependent, of course, but 128-byte +** alignment seems to work well for all contemporary processors. +** Experiments show that 64 works just as well most of the time, but +** the internet says that 128-byte alignment works better. */ -static sqlite3_mutex winMutex_staticMutexes[12]; +static ALIGN128 union staticMutexes { + sqlite3_mutex m; + char spacer[128]; +} aWindowsMutex[12]; static int winMutex_isInit = 0; /* As the winMutexInit() and winMutexEnd() functions are called as part @@ -112,8 +122,8 @@ static int winMutexInit(void){ /* The first to increment to 1 does actual initialization */ if( InterlockedCompareExchange(&winMutex_lock, 1, 0)==0 ){ int i; - for(i=0; iid = i+2; InitializeSRWLock(&p->u.srwl); #ifdef SQLITE_DEBUG @@ -216,12 +226,12 @@ static sqlite3_mutex *winMutexAlloc(int iType){ } default: { #ifdef SQLITE_ENABLE_API_ARMOR - if( iType-2<0 || iType-2>=ArraySize(winMutex_staticMutexes) ){ + if( iType-2<0 || iType-2>=ArraySize(aWindowsMutex) ){ (void)SQLITE_MISUSE_BKPT; return 0; } #endif - p = &winMutex_staticMutexes[iType-2]; + p = &aWindowsMutex[iType-2].m; #ifdef SQLITE_DEBUG #ifdef SQLITE_WIN32_MUTEX_TRACE_STATIC InterlockedCompareExchange(&p->trace, 1, 0);