Memory leak when upgrading from 11.3.1 to 2018.3

[darbois__matthieu]

The reproducer code below did not leak with MKL 11.3.1 but does with MKL 2018.3

Please ignore the (known) 2 leaks from dlopen that will be suppressed.

Tested on CentOS 7

#include <mkl.h>

int main(int argc, char* argv[])
{
	mkl_thread_free_buffers();
	mkl_free_buffers();
	return 0;
}

gcc -m64 -I${MKLROOT}/include -o mkl_test mkl_test.c  -Wl,--start-group ${MKLROOT}/lib/intel64/libmkl_intel_lp64.a ${MKLROOT}/lib/intel64/libmkl_sequential.a ${MKLROOT}/lib/intel64/libmkl_core.a -Wl,--end-group -lpthread -lm -ldl
valgrind -v --tool=memcheck --track-origins=yes --leak-check=full --leak-resolution=high --show-reachable=yes ./mkl_test

==10454== Memcheck, a memory error detector
==10454== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==10454== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==10454== Command: ./mkl_test
==10454==
--10454-- Valgrind options:
--10454--    -v
--10454--    --tool=memcheck
--10454--    --track-origins=yes
--10454--    --leak-check=full
--10454--    --leak-resolution=high
--10454--    --show-reachable=yes
--10454-- Contents of /proc/version:
--10454--   Linux version 3.10.0-693.17.1.el7.x86_64 (builder@kbuilder.dev.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC) ) #1 SMP Thu Jan 25 20:13:58 UTC 2018
--10454--
--10454-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-avx-avx2-bmi
--10454-- Page sizes: currently 4096, max supported 4096
--10454-- Valgrind library directory: /usr/lib64/valgrind
--10454-- Reading syms from /home/user/mkl_test
--10454-- Reading syms from /usr/lib64/ld-2.17.so
--10454--   Considering /usr/lib/debug/usr/lib64/ld-2.17.so.debug ..
--10454--   .. CRC mismatch (computed 790ea11e wanted 61e7c7aa)
--10454-- Reading syms from /usr/lib64/valgrind/memcheck-amd64-linux
--10454--    object doesn't have a symbol table
--10454--    object doesn't have a dynamic symbol table
--10454-- Scheduler: using generic scheduler lock implementation.
--10454-- Reading suppressions file: /usr/lib64/valgrind/default.supp
==10454== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-10454-by-user-on-centos7
==10454== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-10454-by-user-on-centos7
==10454== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-10454-by-user-on-centos7
==10454==
==10454== TO CONTROL THIS PROCESS USING vgdb (which you probably
==10454== don't want to do, unless you know exactly what you're doing,
==10454== or are doing some strange experiment):
==10454==   /usr/lib64/valgrind/../../bin/vgdb --pid=10454 ...command...
==10454==
==10454== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==10454==   /path/to/gdb ./mkl_test
==10454== and then give GDB the following command
==10454==   target remote | /usr/lib64/valgrind/../../bin/vgdb --pid=10454
==10454== --pid is optional if only one valgrind process is running
==10454==
--10454-- REDIR: 0x40192f0 (ld-linux-x86-64.so.2:strlen) redirected to 0x38058d51 (???)
--10454-- REDIR: 0x40190c0 (ld-linux-x86-64.so.2:index) redirected to 0x38058d6b (???)
--10454-- Reading syms from /usr/lib64/valgrind/vgpreload_core-amd64-linux.so
--10454-- Reading syms from /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so
==10454== WARNING: new redirection conflicts with existing -- ignoring it
--10454--     old: 0x040192f0 (strlen              ) R-> (0000.0) 0x38058d51 ???
--10454--     new: 0x040192f0 (strlen              ) R-> (2007.0) 0x04c2ca90 strlen
--10454-- REDIR: 0x4019270 (ld-linux-x86-64.so.2:strcmp) redirected to 0x4c2dbe0 (strcmp)
--10454-- REDIR: 0x4019e60 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x4c30c60 (mempcpy)
--10454-- Reading syms from /usr/lib64/libpthread-2.17.so
--10454--   Considering /usr/lib/debug/usr/lib64/libpthread-2.17.so.debug ..
--10454--   .. CRC mismatch (computed 3a2d64c4 wanted f10d0e71)
--10454-- Reading syms from /usr/lib64/libm-2.17.so
--10454--   Considering /usr/lib/debug/usr/lib64/libm-2.17.so.debug ..
--10454--   .. CRC mismatch (computed 891563a8 wanted 9154abae)
--10454-- Reading syms from /usr/lib64/libdl-2.17.so
--10454--   Considering /usr/lib/debug/usr/lib64/libdl-2.17.so.debug ..
--10454--   .. CRC mismatch (computed 0991f466 wanted 053c8f89)
--10454-- Reading syms from /usr/lib64/libc-2.17.so
--10454--   Considering /usr/lib/debug/usr/lib64/libc-2.17.so.debug ..
--10454--   .. CRC mismatch (computed 80a68b7f wanted 7faa757e)
--10454-- REDIR: 0x55e1f80 (libc.so.6:strcasecmp) redirected to 0x4a247b0 (_vgnU_ifunc_wrapper)
--10454-- REDIR: 0x55ded00 (libc.so.6:strnlen) redirected to 0x4a247b0 (_vgnU_ifunc_wrapper)
--10454-- REDIR: 0x55e4250 (libc.so.6:strncasecmp) redirected to 0x4a247b0 (_vgnU_ifunc_wrapper)
--10454-- REDIR: 0x55e1760 (libc.so.6:memset) redirected to 0x4a247b0 (_vgnU_ifunc_wrapper)
--10454-- REDIR: 0x55e1710 (libc.so.6:memcpy@GLIBC_2.2.5) redirected to 0x4a247b0 (_vgnU_ifunc_wrapper)
--10454-- REDIR: 0x55dec20 (libc.so.6:__GI_strlen) redirected to 0x4c2c9f0 (__GI_strlen)
--10454-- REDIR: 0x55e06f0 (libc.so.6:__GI_strrchr) redirected to 0x4c2c450 (__GI_strrchr)
--10454-- REDIR: 0x55e17c0 (libc.so.6:__GI_memset) redirected to 0x4c2fe80 (memset)
--10454-- REDIR: 0x55d8ab0 (libc.so.6:calloc) redirected to 0x4c2b8df (calloc)
--10454-- REDIR: 0x55d80c0 (libc.so.6:malloc) redirected to 0x4c29b5c (malloc)
--10454-- REDIR: 0x55d84c0 (libc.so.6:free) redirected to 0x4c2ac56 (free)
==10454==
==10454== HEAP SUMMARY:
==10454==     in use at exit: 87 bytes in 3 blocks
==10454==   total heap usage: 4 allocs, 1 frees, 134 bytes allocated
==10454==
==10454== Searching for pointers to 3 not-freed blocks
==10454== Checked 195,944 bytes
==10454==
==10454== 8 bytes in 1 blocks are still reachable in loss record 1 of 3
==10454==    at 0x4C29BE3: malloc (vg_replace_malloc.c:299)
==10454==    by 0x406FF1: mkl_serv_thread_free_buffers (in /home/user/mkl_test)
==10454==    by 0x4010C0: main (in /home/user/mkl_test)
==10454==
==10454== 32 bytes in 1 blocks are still reachable in loss record 2 of 3
==10454==    at 0x4C2B975: calloc (vg_replace_malloc.c:711)
==10454==    by 0x535561F: _dlerror_run (in /usr/lib64/libdl-2.17.so)
==10454==    by 0x5355050: dlopen@@GLIBC_2.2.5 (in /usr/lib64/libdl-2.17.so)
==10454==    by 0x40D432: mkl_serv_inspector_suppress (in /home/user/mkl_test)
==10454==    by 0x40D38C: mkl_serv_lock (in /home/user/mkl_test)
==10454==    by 0x407032: mkl_serv_thread_free_buffers (in /home/user/mkl_test)
==10454==    by 0x4010C0: main (in /home/user/mkl_test)
==10454==
==10454== 47 bytes in 1 blocks are still reachable in loss record 3 of 3
==10454==    at 0x4C29BE3: malloc (vg_replace_malloc.c:299)
==10454==    by 0x400F0D0: _dl_signal_error (in /usr/lib64/ld-2.17.so)
==10454==    by 0x40133A1: _dl_open (in /usr/lib64/ld-2.17.so)
==10454==    by 0x5354FBA: dlopen_doit (in /usr/lib64/libdl-2.17.so)
==10454==    by 0x400F2D3: _dl_catch_error (in /usr/lib64/ld-2.17.so)
==10454==    by 0x53555BC: _dlerror_run (in /usr/lib64/libdl-2.17.so)
==10454==    by 0x5355050: dlopen@@GLIBC_2.2.5 (in /usr/lib64/libdl-2.17.so)
==10454==    by 0x40D432: mkl_serv_inspector_suppress (in /home/user/mkl_test)
==10454==    by 0x40D38C: mkl_serv_lock (in /home/user/mkl_test)
==10454==    by 0x407032: mkl_serv_thread_free_buffers (in /home/user/mkl_test)
==10454==    by 0x4010C0: main (in /home/user/mkl_test)
==10454==
==10454== LEAK SUMMARY:
==10454==    definitely lost: 0 bytes in 0 blocks
==10454==    indirectly lost: 0 bytes in 0 blocks
==10454==      possibly lost: 0 bytes in 0 blocks
==10454==    still reachable: 87 bytes in 3 blocks
==10454==         suppressed: 0 bytes in 0 blocks
==10454==
==10454== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==10454== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

[Gennady_F_Intel]

interesting, thanks for report, we will check. meantime, did you try to use Intel Inspector to check if this problem will be detected by this tool also?

[Gennady_F_Intel]

hello, the issue is reproduced and escalated on our side, thanks for the case. we will keep you inform when some updates would be available. In the case if you have priority support, please submit the ticket to  the intel online service center and share with us your business needs. Thanks, Gennady

[darbois__matthieu]

Thanks for the update

[Gennady_F_Intel]

the fix of the problem will be available into the next MKL v.2019 u2.