spec: memleak

[markus2330]

Memleak in spec:

==27680== 549 (48 direct, 501 indirect) bytes in 1 blocks are definitely lost in loss record 281 of 281
==27680==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==27680==    by 0x4E615E3: ksVNew (keyset.c:174)
==27680==    by 0x4E6175B: ksNew (keyset.c:155)
==27680==    by 0x4E6178A: ksDup (keyset.c:233)
==27680==    by 0x4F10196: elektraSpecGet (spec.c:1155)
==27680==    by 0x4EA87E4: runPlugins (list.c:274)
==27680==    by 0x4EA8AB9: elektraListGet (list.c:332)
==27680==    by 0x4E55390: kdbGet (kdb.c:691)
==27680==    by 0x51A9E45: elektraOpen (getenv.cpp:439)

Looking into it, it seems even more severe:
It seems like spec expects exactly "get, set, get, set" order of being called. In general this this not true. It is perfectly ok to have only "get"; or "get, set, set".

Tip: For cleanup purposes you can use close. See statechart in doc/images/state.png

[tom-wa]

I'll fix that after i get the new global hooks working, because it's somewhat related.

[markus2330]

Ok.

[markus2330]

Seems to be same problem, but now with one line offset:

==30307== 1,673 (48 direct, 1,625 indirect) bytes in 1 blocks are definitely lost in loss record 218 of 220
==30307==    at 0x4C28C20: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==30307==    by 0x4E60913: ksVNew (keyset.c:174)
==30307==    by 0x4E60A8B: ksNew (keyset.c:155)
==30307==    by 0x4E60ABA: ksDup (keyset.c:233)
==30307==    by 0x4F18086: elektraSpecGet (spec.c:1154)
==30307==    by 0x4EAC114: runPlugins (list.c:274)
==30307==    by 0x4EAC3E9: elektraListGet (list.c:332)
==30307==    by 0x4E5A490: kdbGet (kdb.c:691)
==30307==    by 0x51B54F5: elektraOpen (getenv.cpp:439)
==30307==    by 0x4174AE: GetEnv_NameArgv0_Test::TestBody() (test_getenv.cpp:131)
==30307==    by 0x440411: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2134)
==30307==    by 0x430D43: testing::Test::Run() (gtest.cc:2151)

When using default mountpoint its quite confusing, then it looks like that dump is the leaker (which is not true, dump correctly assembles the keyset, but it is processed wrongly later):

==30304== 3 bytes in 3 blocks are indirectly lost in loss record 1 of 220
==30304==    at 0x4C28C20: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==30304==    by 0x4E59267: keySetRaw (keyvalue.c:535)
==30304==    by 0x4E78598: dump::unserialise(std::istream&, ckdb::_Key*, ckdb::_KeySet*) (dump.cpp:137)
==30304==    by 0x4E798FF: elektraDumpGet (dump.cpp:224)
==30304==    by 0x4E5A327: elektraGetDoUpdate (kdb.c:516)
==30304==    by 0x4E5A327: kdbGet (kdb.c:671)
==30304==    by 0x51B54A1: elektraOpen (getenv.cpp:427)
==30304==    by 0x51B5756: (below main) (getenv.cpp:487)

[markus2330]

Btw if someone needs it: workaround is kdb rm -r system/elektra/globalplugins

[tom-wa]

this should be fixed with #555
forgot to reference it.

[markus2330]

kdb global-mount
kdb ls /tests

==10289== 136 bytes in 1 blocks are indirectly lost in loss record 4 of 9
==10289==    at 0x4C28C20: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10289==    by 0x4E3C336: ksVNew (keyset.c:188)
==10289==    by 0x4E3C47B: ksNew (keyset.c:155)
==10289==    by 0x4E3C4AA: ksDup (keyset.c:233)
==10289==    by 0xC539E5E: ???
==10289==    by 0x74E3854: ???
==10289==    by 0x74E3B2A: ???
==10289==    by 0x5046ADB: elektraGetDoUpdateWithGlobalHooks.isra.2 (kdb.c:566)
==10289==    by 0x5047866: kdbGet (kdb.c:740)
==10289==    by 0x432542: get (kdb.hpp:183)
==10289==    by 0x432542: get (kdb.hpp:166)
==10289==    by 0x432542: Cmdline::Cmdline(int, char**, Command*) (cmdline.cpp:271)
==10289==    by 0x416D98: main (main.cpp:115)
==10289== 
==10289== 184 (48 direct, 136 indirect) bytes in 1 blocks are definitely lost in loss record 5 of 9
==10289==    at 0x4C28C20: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10289==    by 0x4E3C303: ksVNew (keyset.c:174)
==10289==    by 0x4E3C47B: ksNew (keyset.c:155)
==10289==    by 0x4E3C4AA: ksDup (keyset.c:233)
==10289==    by 0xC539E5E: ???
==10289==    by 0x74E3854: ???
==10289==    by 0x74E3B2A: ???
==10289==    by 0x5046ADB: elektraGetDoUpdateWithGlobalHooks.isra.2 (kdb.c:566)
==10289==    by 0x5047866: kdbGet (kdb.c:740)
==10289==    by 0x432542: get (kdb.hpp:183)
==10289==    by 0x432542: get (kdb.hpp:166)
==10289==    by 0x432542: Cmdline::Cmdline(int, char**, Command*) (cmdline.cpp:271)
==10289==    by 0x416D98: main (main.cpp:115)

[tom-wa]

caused that on in the last PR, i'm still trying to figure out the actual problem.

[markus2330]

Thank you, then lets keep the issue open for this new problem.

[tom-wa]

should both be fixed by now.

[tom-wa]

btw, RTLD_NODELETE helps resolving the ??? parts.

[markus2330]

There are still memleaks:

==6309== 1 bytes in 1 blocks are indirectly lost in loss record 1 of 755
==6309==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==6309==    by 0x52F76C3: elektraStrNDup (internal.c:298)
==6309==    by 0x52FAD12: keySetMeta (keymeta.c:499)
==6309==    by 0x52FFA69: keySetBinary (keyvalue.c:482)
==6309==    by 0x5300097: elektraModulesLoad (static.c:94)
==6309==    by 0x52FDA82: elektraPluginOpen (plugin.c:273)
==6309==    by 0x53394F6: runPlugins (list.c:263)
==6309==    by 0x5339984: elektraListSet (list.c:362)
==6309==    by 0x52F0F3E: elektraSetPrepare (kdb.c:877)
==6309==    by 0x52F0F3E: kdbSet (kdb.c:1122)
==6309==    by 0x418364: set (kdb.hpp:227)
==6309==    by 0x418364: MergingKDBTest_HandlesUnconflictingKeySets_Test::TestBody() (testtool_mergingkdb.cpp:74)

or:

==6309== 1 bytes in 1 blocks are indirectly lost in loss record 2 of 755
==6309==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==6309==    by 0x52F76C3: elektraStrNDup (internal.c:298)
==6309==    by 0x52FAD12: keySetMeta (keymeta.c:499)
==6309==    by 0x52FFA69: keySetBinary (keyvalue.c:482)
==6309==    by 0x52FB8E0: keyVInit (keyhelpers.c:362)
==6309==    by 0x52F7136: keyVNew (key.c:217)
==6309==    by 0x52F71D0: keyNew (key.c:199)
==6309==    by 0x5339539: runPlugins (list.c:269)
==6309==    by 0x5339984: elektraListSet (list.c:362)
==6309==    by 0x52F0F3E: elektraSetPrepare (kdb.c:877)
==6309==    by 0x52F0F3E: kdbSet (kdb.c:1122)
==6309==    by 0x418364: set (kdb.hpp:227)
==6309==    by 0x418364: MergingKDBTest_HandlesUnconflictingKeySets_Test::TestBody() (testtool_mergingkdb.cpp:74)

[markus2330]

@tom-wa I think some of these memleaks are still open.

Can you reproduce them with a shellrecorder script?