[Valgrind-users] memory leak reported many times, but only one instance should be possible

[Gordon M. <gor...@gm...>]

I'm working on eliminating memory leaks in PackageKit, and I'd like to 
know more about whether I should suppress one of the results I'm getting.

The code in question is dynamically loaded at runtime, but as far as I 
know, it's only loaded once and unloaded at exit.

When I exit packagekitd, after even a very short run, I get one 
particular stack over a hundred times in valgrind's output.  If I got 
this stack once, then I would conclude that it was a leak I could 
ignore: memory allocated for global state one time.  But because it's 
reported repeatedly, I'm not sure how to interpret the output.

The other reason that I find this very strange is that there are 
actually two mechanisms that should both individually guarantee that 
this allocation only happens once.  The rpm Lua INITSTATE should only 
call rpmluaNew if the static variable globalLuaState is null, and libdnf 
calls rpmReadConfigFiles in a g_once_init_enterblock.

Can anyone suggest why valgrind prints so many loss records for this 
particular leak?  Links for the two functions that I mentioned follow, 
along with one of the loss records printed by valgrind.


https://github.com/rpm-software-management/rpm/blob/master/rpmio/rpmlua.c#L93

https://github.com/rpm-software-management/libdnf/blob/dnf-4-master/libdnf/dnf-context.cpp#L400

==49724== 24 bytes in 1 blocks are possibly lost in loss record 1,247 of 
4,550
==49724==    at 0x484378A: malloc (vg_replace_malloc.c:392)
==49724==    by 0x484870B: realloc (vg_replace_malloc.c:1451)
==49724==    by 0x14F60600: luaM_malloc_ (lmem.c:192)
==49724==    by 0x14F6B047: UnknownInlinedFun (ltable.c:490)
==49724==    by 0x14F6B047: UnknownInlinedFun (ltable.c:478)
==49724==    by 0x14F6B047: luaH_resize (ltable.c:558)
==49724==    by 0x14F4CE34: lua_createtable (lapi.c:772)
==49724==    by 0x14F68F43: UnknownInlinedFun (loadlib.c:732)
==49724==    by 0x14F68F43: luaopen_package (loadlib.c:740)
==49724==    by 0x14F5A671: UnknownInlinedFun (ldo.c:507)
==49724==    by 0x14F5A671: luaD_precall (ldo.c:573)
==49724==    by 0x14F522D7: UnknownInlinedFun (ldo.c:608)
==49724==    by 0x14F522D7: UnknownInlinedFun (ldo.c:628)
==49724==    by 0x14F522D7: lua_callk (lapi.c:1022)
==49724==    by 0x14F5280B: luaL_requiref (lauxlib.c:976)
==49724==    by 0x14F5D6E3: luaL_openlibs (linit.c:61)
==49724==    by 0x14815163: rpmluaNew (rpmlua.c:128)
==49724==    by 0x14815340: UnknownInlinedFun (rpmlua.c:96)
==49724==    by 0x14815340: rpmluaGetGlobalState (rpmlua.c:93)
==49724==    by 0x14B83E4C: rpmReadConfigFiles (rpmrc.c:1662)
==49724==    by 0x146EA173: dnf_context_globals_init (in 
/usr/lib64/libdnf.so.2)
==49724==    by 0x1475B155: ??? (in /usr/lib64/libdnf.so.2)
==49724==    by 0x1475B66A: 
libdnf::getUserAgent(std::map<std::__cxx11::basic_string<char, 
std::char_traits<char>, std::allocator<char> >, 
std::__cxx11::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::less<std::__cxx11::basic_string<char, 
std::char_traits<char>, std::allocator<char> > >, 
std::allocator<std::pair<std::__cxx11::basic_string<char, 
std::char_traits<char>, std::allocator<char> > const, 
std::__cxx11::basic_string<char, std::char_traits<char>, 
std::allocator<char> > > > > const&) (in /usr/lib64/libdnf.so.2)
==49724==    by 0x1475BC99: libdnf::getUserAgent[abi:cxx11]() (in 
/usr/lib64/libdnf.so.2)
==49724==    by 0x146EC07F: ??? (in /usr/lib64/libdnf.so.2)
==49724==    by 0x4A5B0E7: g_type_create_instance (gtype.c:1931)
==49724==    by 0x4A40C1F: g_object_new_internal (gobject.c:2228)
==49724==    by 0x4A42247: g_object_new_with_properties (gobject.c:2391)
==49724==    by 0x4A42FF0: g_object_new (gobject.c:2037)
==49724==    by 0x146F2375: dnf_context_new (in /usr/lib64/libdnf.so.2)
==49724==    by 0x48616BB: pk_backend_ensure_default_dnf_context 
(pk-backend-dnf.c:225)
==49724==    by 0x486757D: pk_backend_initialize (pk-backend-dnf.c:289)