Skip to content

Investigate Valgrind issues with libsqlite3

With !835 (merged), the Valgrind failures should be fixed. However, we are still seeing some curious output (job link):

2025-04-09T13:22:50.894659Z 01O vg: Apr 09 15:22:50 ==19280== 32 bytes in 1 blocks are possibly lost in loss record 3,646 of 8,100
2025-04-09T13:22:50.894661Z 01O vg: Apr 09 15:22:50 ==19280==    at 0x484C214: calloc (vg_replace_malloc.c:1675)
2025-04-09T13:22:50.894663Z 01O vg: Apr 09 15:22:50 ==19280==    by 0x1263D685: __trans_list_add (in /usr/lib64/libnl-3.so.200.26.0)
2025-04-09T13:22:50.894669Z 01O vg: Apr 09 15:22:50 ==19280==    by 0x125B2FD2: ??? (in /usr/lib64/libnl-route-3.so.200.26.0)
2025-04-09T13:22:50.894670Z 01O vg: Apr 09 15:22:50 ==19280==    by 0x400551D: call_init (dl-init.c:70)
2025-04-09T13:22:50.894672Z 01O vg: Apr 09 15:22:50 ==19280==    by 0x400551D: call_init (dl-init.c:26)
2025-04-09T13:22:50.894675Z 01O vg: Apr 09 15:22:50 ==19280==    by 0x400560B: _dl_init (dl-init.c:117)
2025-04-09T13:22:50.894677Z 01O vg: Apr 09 15:22:50 ==19280==    by 0x401D889: ??? (in /usr/lib64/ld-linux-x86-64.so.2)
2025-04-09T13:22:50.894679Z 01O vg: Apr 09 15:22:50 ==19280==    by 0x1: ???
2025-04-09T13:22:50.894681Z 01O vg: Apr 09 15:22:50 ==19280==    by 0x1FFEFFD996: ???
2025-04-09T13:22:50.894683Z 01O vg: Apr 09 15:22:50 ==19280==    by 0x1FFEFFD9AD: ???
2025-04-09T13:22:50.894685Z 01O vg: Apr 09 15:22:50 ==19280== 
2025-04-09T13:22:50.894687Z 01O vg: Apr 09 15:22:50 {
2025-04-09T13:22:50.894688Z 01O vg: Apr 09 15:22:50    <insert_a_suppression_name_here>
2025-04-09T13:22:50.894690Z 01O vg: Apr 09 15:22:50    Memcheck:Leak
2025-04-09T13:22:50.894692Z 01O vg: Apr 09 15:22:50    match-leak-kinds: possible
2025-04-09T13:22:50.894693Z 01O vg: Apr 09 15:22:50    fun:calloc
2025-04-09T13:22:50.894695Z 01O vg: Apr 09 15:22:50    fun:__trans_list_add
2025-04-09T13:22:50.894698Z 01O vg: Apr 09 15:22:50    obj:/usr/lib64/libnl-route-3.so.200.26.0
2025-04-09T13:22:50.894699Z 01O vg: Apr 09 15:22:50    fun:call_init
2025-04-09T13:22:50.894700Z 01O vg: Apr 09 15:22:50    fun:call_init
2025-04-09T13:22:50.894703Z 01O vg: Apr 09 15:22:50    fun:_dl_init
2025-04-09T13:22:50.894704Z 01O vg: Apr 09 15:22:50    obj:/usr/lib64/ld-linux-x86-64.so.2
2025-04-09T13:22:50.894706Z 01O vg: Apr 09 15:22:50    obj:*
2025-04-09T13:22:50.894708Z 01O vg: Apr 09 15:22:50    obj:*
2025-04-09T13:22:50.894709Z 01O vg: Apr 09 15:22:50    obj:*
2025-04-09T13:22:50.894711Z 01O vg: Apr 09 15:22:50 }
2025-04-09T13:22:50.894713Z 01O vg: Apr 09 15:22:50 ==19280== 4,104 bytes in 1 blocks are possibly lost in loss record 8,039 of 8,100
2025-04-09T13:22:50.894716Z 01O vg: Apr 09 15:22:50 ==19280==    at 0x484482F: malloc (vg_replace_malloc.c:446)
2025-04-09T13:22:50.894719Z 01O vg: Apr 09 15:22:50 ==19280==    by 0x7CF814A: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
2025-04-09T13:22:50.894725Z 01O vg: Apr 09 15:22:50 ==19280==    by 0x7CF4D50: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
2025-04-09T13:22:50.894728Z 01O vg: Apr 09 15:22:50 ==19280==    by 0x7CFC37B: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
2025-04-09T13:22:50.894731Z 01O vg: Apr 09 15:22:50 ==19280==    by 0x7D01A17: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
2025-04-09T13:22:50.894735Z 01O vg: Apr 09 15:22:50 ==19280==    by 0x7D0C323: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
2025-04-09T13:22:50.894739Z 01O vg: Apr 09 15:22:50 ==19280==    by 0x7D1E879: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
2025-04-09T13:22:50.894742Z 01O vg: Apr 09 15:22:50 ==19280==    by 0x7D1B49F: sqlite3_step (in /usr/lib64/libsqlite3.so.0.8.6)
2025-04-09T13:22:50.894750Z 01O vg: Apr 09 15:22:50 ==19280==    by 0x7CCD55B: cta::rdbms::wrapper::SqliteStmt::executeNonQuery() (in /usr/lib64/libctardbmssqlite.so.0.1.0)
2025-04-09T13:22:50.894760Z 01O vg: Apr 09 15:22:50 ==19280==    by 0x7CB558D: cta::rdbms::wrapper::SqliteConn::executeNonQuery(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (in /usr/lib64/libctardbmssqlite.so.0.1.0)
2025-04-09T13:22:50.894763Z 01O vg: Apr 09 15:22:50 ==19280==    by 0x777EDB7: cta::rdbms::Conn::executeNonQuery(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (in /usr/lib64/libctardbms.so.0.1.0)
2025-04-09T13:22:50.894769Z 01O vg: Apr 09 15:22:50 ==19280==    by 0x76828A6: cta::catalogue::SchemaCreatingSqliteCatalogue::executeNonQueries(cta::rdbms::Conn&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const (in /usr/lib64/libctacatalogue.so.0.1.0)
2025-04-09T13:22:50.894774Z 01O vg: Apr 09 15:22:50 ==19280==

My guess is that this is due to sqlite's internal caching mechanism and that this is harmless. We should however, confirm this.

Additionally, said MR removed --show-reachable=yes from the Valgrind output as this is generally harmless and it was producing too much output for GitLab to save. This seems to have started from this commit onwards. At some point, we might want to investigate this further...