Libelektra: MemCheck: target not detecting memory problems

[mpranj]

The MemCheck target stopped detecting memory problems, as has been verified in #2308.

Similar problem was already mentioned in #1876.

The description will be very brief, I am working on a fix already.

Steps to Reproduce the Problem

Build libelektra.

make run_memcheck

Expected Result

Return value should be non-zero on memory problems. That way the build systems detect memory problems.

Actual Result

Return value is zero and does not detect memory problems.

System Information

• Elektra Version: master

[markus2330]

Thank you so much for finding this problem and working on it!

[mpranj]

Two things regarding #2308:

1. Is it ok if we let valgind track child processes too? I think this could make sense.
2. I would like to add parallel jobs to run_memcheck as it is already the case for run_all. Hope this is fine.

[markus2330]

1. yes, it makes sense!
2. yes, thank you!

I think both cases were oversights.

[mpranj]

It seems that quite some valgrind errors appear in the build system. All of them seem to be tied to the builds having ENABLE_DEBUG=OFF. When set to ON, the memcheck runs fine on the build servers.

It would make sense if ENABLE_DEBUG would enable debug symbols or so, but according to docu it does not. Can anyone make sense of that?

A lot of errors occur when it is off. It seems that they might be false positives and that they just somehow don't match the suppressions.
See log: MemoryChecker.251.log

I would appreciate input if there are ideas.

[markus2330]

Thank you for digging deeper here!

ENABLE_DEBUG adds RTLD_NODELETE to dlopen and this might cause the problems: with NODELETE the libraries are not unloaded anymore. I documented this in eaadbb9d4c56ca36c2cc3168d75e6ec48fd238ac

So in as ENABLE_DEBUG is now, it seems to break the memcheck tests. So for now we could simply not run the memcheck tests for ENABLE_DEBUG (but let it run for ENABLE_LOGGER).

[mpranj]

Thank you for adding the docs.

So in as ENABLE_DEBUG is now, it seems to break the memcheck tests. So for now we could simply not run the memcheck tests for ENABLE_DEBUG (but let it run for ENABLE_LOGGER).

This last part is confusing me. Just to reiterate:

• ENABLE_DEBUG=ON: memcheck runs OK
• ENABLE_DEBUG=OFF: memcheck fails

So we would have to run memcheck with ENABLE_DEBUG to succeed, which contradicts with what you said above?!

[markus2330]

Thank you for reiterating, I actually misunderstood because the behavior is quite unexpected. (I expected the libs to not cleanup because of RTLD_NODELETE but this does not seem to be the problem then.)

Locally, I get also memleaks with ENABLE_DEBUG=ON (when adding --trace-children=yes --leak-check=full):

==19951== HEAP SUMMARY:
==19951==     in use at exit: 84,878 bytes in 35 blocks
==19951==   total heap usage: 1,001 allocs, 966 frees, 323,882 bytes allocated
==19951== 
<b>MLK</b> ==19951== 4 bytes in 1 blocks are definitely lost in loss record 1 of 26
==19951==    at 0x4C2BBAF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19951==    by 0x10B6F4: elektraDummyOpen (testlib_pluginprocess.c:28)
==19951==    by 0x10A118: test_communication (testlib_pluginprocess.c:121)
==19951==    by 0x10A118: main (testlib_pluginprocess.c:423)

which seem to be actual mem-leaks. I wonder why the build server does not find them?

In any case: we should add the mem checks for the children to the build server asap. Otherwise PRs might easily add new regressions.

[mpranj]

The memproblem you mentioned is fixed in my PR.