|
From: Gordon M. <gor...@gm...> - 2023-01-16 21:02:23
|
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) |
|
From: Paul F. <pj...@wa...> - 2023-01-16 22:04:24
|
On 16-01-23 22:02, Gordon Messmer wrote: > 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. In my experience the most likely reason that you are getting a large number of leaks reported by Valgrind is that there is a large number of leaks. You need more stack depth to see all of the stack. Otherwise you can use gdb and put a breakpoint on malloc to confirm the allocations. A+ Paul |
|
From: Gordon M. <gor...@gm...> - 2023-01-16 22:05:54
|
On 2023-01-16 13:02, Gordon Messmer wrote: > Can anyone suggest why valgrind prints so many loss records for this > particular leak? Well, now I feel very silly, because these loss records are *not* 100% identical, and valgrind is actually reporting that rpmluaNew makes > 100 separate allocations. Sorry for the noise. |