mkl_sparse_d_create_csr : possibility of memory leak

[dimdol10]

Hello everyone, 

I am using parallel studio xe 2020 in visual studio community 2019 (version 16.8.3).

I found that MKL_SPARSE_DESTROY of a matrix handle generated by the function 'mkl_sparse_d_create_csr' does not deallocate all the memory (heap) allocated within the function. I have checked the amount of memory usage with the diagnostic tool of visual studio, which clearly showed that the increased 'Allocations (265)' and 'Heap Size (129.13KB)' does not completely freed by 'MKL_SPARSE_DESTROY'.

Please find the attached example FORTRAN code.

Thank you very much.

[Kirill_V_Intel]

Hello!

In your example you allocate CSR data  in the code calling oneMKL, so the sparse handle does not own the data and cannot destroy it within mkl_sparse_destroy. Rule of thumb when dealing with memory is: whoever allocates memory is responsible for freeing it.

Routine mkl_sparse_destroy deallocates all data associated with the handle which is owned by the handle and cannot touch user-allocated data (it cannot even know what is the right deallocating routine, e.g.) passed to create_csr.

As an example of a case when the handle owns the data: if the sparse handle is created as a result of, say, mkl_sparse_sp2m, the output CSR data will be owned by the handle (because it will be allocated internally by mkl_sparse_sp2m) and get destroyed within mkl_sparse_destroy call.

Additionally, to have a proper check for memory leaks on the side of MKL, you can use mkl_mem_stat with mkl_free_buffers routines, see https://software.intel.com/content/www/us/en/develop/documentation/onemkl-developer-reference-fortran/top/support-functions/memory-management/mkl-mem-stat.html and https://software.intel.com/content/www/us/en/develop/documentation/onemkl-developer-reference-fortran/top/support-functions/memory-management/mkl-free-buffers.html.

Best,
Kirill

[dimdol10]

Dear Kirill, 

Many thanks to your reply and helpful suggestions.

Unfortunately, it is still unclear for me why the memory allocated inside the routine 'mkl_sparse_d_create_csr' has not been completely freed. What I further did following up your reply was to deallocate the user-allocated data, which are those constituents of 'matA' in the attached code; however, the amount of 'allocations' and 'heap size' freed by this deallocation is much less than that allocated by the routine 'mkl_sparse_d_create_csr'. Please find the attached figure for investigating the memory usage. 

In the attached figure, we clearly see that

1) The amount of allocations and heap size by the routine 'mkl_sparse_d_create_csr' (from the break point number  '2' to '3') is much larger than the allocation of user-allocated data 'matA' (from the break point number '1' to '2'). 

2) The amount of freed 'Allocations' and 'Heap size' by 'MKL_SPARSE_DESTROY' and the deallocation of user-allocated array (from the break point number 3 to 5) is much less than the amount of allocation by 'mkl_sparse_d_create_csr'.

Thank you very much.

[Kirill_V_Intel · Accepted solution]

Hi again,

As I said, the only legitimate reason I can think of, is that you see the thread local buffers allocated by oneMKL (not related to sparse functionality at all). To deallocate those, you need to call mkl_free_buffers (after the last call to MKL routines in your application)

I've attached a modified example code which calls mkl_free_buffers and reports no leaks either with mkl_mem_stat or with valgrind (on Linux).

I'm not very knowledgeable as to how good is the memory check in VS which you're using but I am pretty sure that there is no memory leak in mkl_sparse_?_create_csr routine.

Best,
Kirill

[ArpitaP_Intel]

Thanks a lot Kirill.

Hi Myung-Jin Choi,

Thanks for reaching out to us and glad to know that your issue is resolved. If you need any additional information, please post a new question as this thread will no longer be monitored by Intel

Thanks!