[Bug] Memory leaks when running z_sub demo

[MelamudMichael]

Describe the bug

Running using valgrind - the result is :

==18814== possibly lost: 15,836 bytes in 99 blocks
==18814== still reachable: 460,256 bytes in 717 blocks

To reproduce

run with the following parameters :
valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes --verbose --log-file=[file name] ./z_sub

System info

redhat docker

[MelamudMichael]

z_sub_valgrind_log.txt

attached log

[fuzzypixelz]

Thanks for reporting this!

I have reproduced the Valgrind report on Ubuntu Aarch64; the summary is as follows:

LEAK SUMMARY:
    definitely lost: 0 bytes in 0 blocks
    indirectly lost: 0 bytes in 0 blocks
    possibly lost: 10,616 bytes in 77 blocks
    still reachable: 264,056 bytes in 376 blocks
    suppressed: 0 bytes in 0 blocks

By "possibly lost" Valgrind means memory to which there may or may not have been a pointer when the program exited. And by "still reachable" Valgrind means memory to which there definitely was a pointer when the program exited. Our numbers are not exactly the same but they're comparable.

To determine whether the size of this leak grows with time, I ran Valgrind on the z_sub example for different periods of time. I saw little variation between runs. Then I modified z_sub to run for 3 minutes and used Instruments to plot the memory usage of z_sub as a function of time. Thus, at least in the case of z_sub the memory leak is "constant" but not all allocations are freed right before the OS reclaims them.

Valgrind shows that there are numerous — and likely distinct in origin — memory leaks at play here. I speculate that some of them may be caused by Arc cycles in Zenoh's internal state, others by various tasks which are spawned and live for the entire duration of the process (e.g. scouting and listening for connections) and not correctly managed.

Of course, these "false" leaks should ideally be hunted down and fixed. We will be investigating them.

[OlivierHecart]

All memory leaks have been fixed by: eclipse-zenoh/zenoh#846.
All the potential leaks reported by valgrind after the fix are static allocations (that Rust does not free at process termination) related to the ZRuntime or the env_logger.