Libelektra: Test for Notification Library Causes Memory Leaks

[sanssecours]

Problem Description

It looks like testlib_notification leaks some memory since we changed the default storage back to dump. This causes problems on Travis where the ASAN enabled Linux build job currently fails.

[markus2330]

Thank you for reporting!

@waht Do you have an idea?

[waht]

Thanks! I had a quick look at the traces but I'm not sure what causes the leak.

I will look into it after finishing changes on the notification library in PR #1825 which should done at the beginning of March.

[markus2330]

Thank you for looking into it so quickly!

The issue might be also related to the mem leak discussed in #1826. (which might be caused by global plugins, like presumably this issue here).

We should add extra tests for mountGlobalPlugin and better test the global plugins in general. Maybe @mpranj will find the problem while testing the placements for the mmap global plugin.

[mpranj]

Interestingly, the leaks in the log all have a root in test_openclose from testlib_notification.c from kdbOpen. The other tests do kdbOpen too, but not with a cascading key. Maybe that is just a random observation though.

[markus2330]

Thanks for looking into it.

If I make a wild guess there is some assumption in the global plugin processing about present keys, which is only fulfilled with INI (because it always adds section keys).

I have some doubts, however, that this is the only problem.

[waht]

Good catch! I gave it a shot but the trace stayed the same.

[markus2330]

So the issue has nothing to do with INI/dump?

[waht]

I was able to locate the source of the "leak". The problem was that the test aborted because kdbOpen() failed due to a missing ASan symbol (__ubsan_vptr_type_cache) in the storage plugin:

root@92a127a364ed:/mnt/share/build_docker# ASAN_OPTIONS=symbolize=1 ASAN_SYMBOLIZER_PATH=/usr/lib/llvm-5.0/bin/llvm-symbolizer ./bin/testlib_notification 
test open & close
src/libs/elektra/kdb.c:260:kdbOpen: called with system/sw/tests/testlib_notification
src/libs/elektra/plugin.c:300:elektraPluginOpen: Finished loading plugin resolver
src/libs/loader/dl.c:88:elektraModulesLoad: Add Warning 1 : of module: libelektra-storage.so, because: /mnt/share/build_docker/lib/libelektra-storage.so: undefined symbol: __ubsan_vptr_type_cache
src/libs/elektra/plugin.c:304:elektraPluginOpen: Failed to load plugin storage@
src/libs/elektra/kdb.c:287:kdbOpen: Add Error 40: could not open default backend
/mnt/share/src/libs/notification/tests/testlib_notification.c:72: fatal in test_openclose: opening kdb failed

When building with clang 3.8 kdbOpen() was fine. I was able to fix clang 5.0 locally by always linkingubsan (undefined behavior library) manually. According to the clang documentation it should be linked automatically by the linker. This fix did not work on Travis: ld could not find the ubsan library

For now I've disabled the vptr sanitizer in my PR.

The clang documentation states that for vptr to work, the source needs to be linked with clang++ - maybe this is the cause of the problem here. Maybe someone knows how check which linker is used or how to change the linker in CMake. I tried setting CMAKE_LINKER but it did not work.

[sanssecours]

The problem was that the test aborted because kdbOpen() failed due to a missing ASan symbol (__ubsan_vptr_type_cache) in the storage plugin

I think we had/have the same problem in in PR #1783. The missing symbols seem to be part of libclang_rt.ubsan_standalone_cxx-x86_64.so. One very ugly fix for the problem is to just preload the library:

export LD_PRELOAD=$(find /usr/ -name '*libclang_rt.ubsan_standalone_cxx-x86_64.so')

, before you run the tests.

[waht]

Jep, it is the same problem. Thank you, the suggestion worked!

If we can't fix the linking, preloading seems like a viable solution. It could be included in the run_asan target (which by the way does not work for me with make run_asan - was it removed?)

[sanssecours]

…which by the way does not work for me with make run_asan - was it removed?

I think there was never a CMake target for the script run_asan:

Then, to use ASAN, run run_asan in the build directory…

.

[waht]

Oh now I see. It's a script, not a make target! :)

[stale[bot]]

I mark this issue stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping the issue by writing a message here or create a new issue with the remainder of this issue.
Thank you for your contributions :sparkling_heart:

[stale[bot]]

I closed this issue now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue.
Thank you for your contributions :sparkling_heart: