Repository navigation
Memory Leak in initializing database #1134
Description
Activity
Memory dump as shared by aks3090 -
Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 0x7f103e232c5f in __interceptor_malloc ../../../../libsanitizer/asan/asan_malloc_linux.cpp:69 #1 0x7f103c2fd570 in sqlite3MemMalloc (/opt/3p/binary/drm-mip2004/lib/libmip_core.so+0x694570) #2 0x7f103c2fe035 in mallocWithAlarm (/opt/3p/binary/drm-mip2004/lib/libmip_core.so+0x695035) #3 0x7f103c2fe0e1 in sqlite3Malloc (/opt/3p/binary/drm-mip2004/lib/libmip_core.so+0x6950e1) #4 0x7f103c2fe815 in sqlite3DbMallocRaw (/opt/3p/binary/drm-mip2004/lib/libmip_core.so+0x695815) #5 0x7f103c301b95 in strAccumFinishRealloc (/opt/3p/binary/drm-mip2004/lib/libmip_core.so+0x698b95) #6 0x7f103c301c59 in sqlite3StrAccumFinish (/opt/3p/binary/drm-mip2004/lib/libmip_core.so+0x698c59) #7 0x7f103c3020af in sqlite3_vmprintf (/opt/3p/binary/drm-mip2004/lib/libmip_core.so+0x6990af) #8 0x7f103c302192 in sqlite3_mprintf (/opt/3p/binary/drm-mip2004/lib/libmip_core.so+0x699192) #9 0x7f103c37cf6f in sqlite3Pragma (/opt/3p/binary/drm-mip2004/lib/libmip_core.so+0x713f6f) #10 0x7f103c3b6a6c in yy_reduce (/opt/3p/binary/drm-mip2004/lib/libmip_core.so+0x74da6c) #11 0x7f103c3b7ee0 in sqlite3Parser (/opt/3p/binary/drm-mip2004/lib/libmip_core.so+0x74eee0) #12 0x7f103c3b91bd in sqlite3RunParser (/opt/3p/binary/drm-mip2004/lib/libmip_core.so+0x7501bd) #13 0x7f103c382162 in sqlite3Prepare (/opt/3p/binary/drm-mip2004/lib/libmip_core.so+0x719162) #14 0x7f103c3823bb in sqlite3LockAndPrepare (/opt/3p/binary/drm-mip2004/lib/libmip_core.so+0x7193bb) #15 0x7f103c3825ce in sqlite3_prepare_v2 (/opt/3p/binary/drm-mip2004/lib/libmip_core.so+0x7195ce) #16 0x7f103c099034 in Microsoft::Applications::Events::OfflineStorage_SQLite::initializeDatabase() (/opt/3p/binary/drm-mip2004/lib/libmip_core.so+0x430034) SUMMARY: AddressSanitizer: 16 byte(s) leaked in 1 allocation(s). FAIL mip_test (exit status: 1)Reason for Leak:
The allocation of this memory happens during LogManager initialization. SqliteDB wrapper will create prepared statement objects during initialization -
cpp_client_telemetry/lib/offline/OfflineStorage_SQLite.cpp
Lines 791 to 793 in 4f3adbd
These objects should be cleaned (by explicitly calling sqlite3_finalize..()) when LogManager is shutdown, but this is missing in code. Since this is one time allocation during startup, in general it should be safe to have. The memory leak will get significant only if the LogManager is frequently reinitialized while the application is running.Hi, is there any update on this issue?
This is pending for review in a future release given this is a one-time operation allocation.
Reacted by Lalit Kumar Bhasin- added a commit that references this issue
on Sep 22, 2026 Addressed in #1520 (commit 82cffa1):
SqliteDBnow calls its idempotent shutdown from its destructor, finalizing prepared statements and closing the database even if the owner did not explicitly callShutdown(). Subsequent storage shutdown hardening is also included in that PR. Closing as likely fixed for the reported initialization/shutdown leak; please reopen with a current sanitizer trace if one remains.
Describe your environment.
This is happening for one of the customer of MIP sdk which used 1DS sdk. MIP sdk just 1DS is cross-platform sdk. Customer environment is windows/linux here.
Steps to reproduce.
Using any memory sanitizer will detect this.
What is the expected behavior?
No memory leak as we have customer who also use this for services.
What is the actual behavior?
What did you see instead?
Additional context.
Discussed with lalit , needed to call sqlite3_finalize..() when logManager is shutdown.