Memory Leak for Kmeans example

[Ocean-Lua]

Describe the bug Memory Leak for kmeans_dense_distr example.The leak info is the following: ==6767== 7,856 (832 direct, 7,024 indirect) bytes in 4 blocks are definitely lost in loss record 46 of 48 ==6767== at 0x4C29BC3: malloc (vg_replace_malloc.c:299) ==6767== by 0x9CEA3C9: fpk_serv_malloc (in /home/daal-2020/__release_lnx_gnu/daal/lib/intel64_lin/libdaal_core.so) ==6767== by 0x75034E6: operator new (algorithm_types.h:64) ==6767== by 0x75034E6: daal::algorithms::kmeans::init::interface2::Distributed<(daal::ComputeStep)0, float, (daal::algorithms::kmeans::init::Method)1>::Distributed(unsigned long, unsigned long, unsigned long) (kmeans_init_dense_random_distr_step1_fpt_dispatcher.cpp:43) ==6767== by 0x41A63F: main (kmeans_dense_distr.cpp:73)

kmeans_init_dense_random_distr_step2_fpt_dispatcher.cpp: kmeans_init_distributed.h: Call "new" operation in the constructor, but there is no "delete" operation in the destruction.

To Reproduce Steps to reproduce the behavior:

1. Setup 1.1 Add the compile parameter -g2 in the build/cmplr.gnu.mk file. 1.2 Compile the DAAL project. 1.3 Setup the env. export DAALROOT=/home/daal-2020 export CPLUS_INCLUDE_PATH=$CPLUS_INCLUDE_PATH:$DAALROOT/__release_lnx_gnu/daal/include export LD_LIBRARY_PATH=$DAALROOT/lib/intel64_lin:$DAALROOT/lib:$DAALROOT/__release_lnx_gnu/tbb/lib/intel64_lin/gcc4.4:$LD_LIBRARY_PATH
2. Call 2.1 Touch daal.lst file,and set the content to be: DAAL = kmeans_dense_distr 2.2 Compile the example: make sointel64 compiler=gnu 2.3 Run example with valgrind valgrind --tool=memcheck --leak-check=full --log-file=./kmeans_dense_distr_memcheck.log _results/gnu_intel64_parallel_so/kmeans_dense_distr.exe > _results/gnu_intel64_parallel_so/kmeans_dense_distr.res
3. See error

Environment:

• OS: Red Hat Enterprise Linux Server release 7.6 (Maipo)
• Compiler: gcc version 8.3.0 (GCC)
• Version: DAAL 2020

[SmirnovEgorRu]

@Ocean-Lua, thank you for reporting the issue, looks like a real problem. @masdevas, could you, please, look at this?

[masdevas]

@SmirnovEgorRu Sure, I will look at this problem as soon as possible.

[egebasturk]

@Ocean-Lua Reproduced and checked it with AddressSanitizer and valgrind. Asan errors were gone when I modified destructor like "virtual ~DistributedBase() { delete(_par); }". Though valgrind still detects 3 blocks of possible leak which can be reached. I'm not experienced so I don't know if this modification is a bad practice.

OS: Ubuntu 18.04.3 GCC 7.4.0