我正在尝试使用英特尔MKL检查器/执行器稀疏BLAS库,但我一直在努力解决mkl_sparse_convert_csr
子例程中内存使用错误的问题。下面这个简单的程序可以重现我的问题:
program debug
use mkl_spblas
use omp_lib
use, intrinsic :: iso_c_binding, only: c_int, c_double
implicit none
integer, parameter :: DIM = 10000
integer :: stat, i
integer(kind = c_int), dimension(DIM) :: irn, jcn
real(kind = c_double), dimension(DIM) :: val
type(sparse_matrix_t) :: mat1, mat2
do i = 1, DIM
irn(i) = i
jcn(i) = i
val(i) = 1.0d0
end do
call omp_set_num_threads(1)
stat = mkl_sparse_d_create_coo (A = mat1, indexing = SPARSE_INDEX_BASE_ONE, &
rows = DIM, cols = DIM, nnz = DIM, row_indx = irn, col_indx = jcn, values = val)
if (stat /= 0) stop 'Error in mkl_sparse_d_create_coo'
stat = mkl_sparse_convert_csr (source = mat1, &
operation = SPARSE_OPERATION_NON_TRANSPOSE, dest = mat2)
if (stat /= 0) stop 'Error in mkl_sparse_convert_csr'
stat = mkl_sparse_destroy (A = mat1)
if (stat /= 0) stop 'Error in mkl_sparse_destroy (mat1)'
stat = mkl_sparse_destroy (A = mat2)
if (stat /= 0) stop 'Error in mkl_sparse_destroy (mat2)'
call mkl_free_buffers
end program debug
当我检查Valgrind时,我得到以下关于内存泄漏的报告:
==27267== Memcheck, a memory error detector
==27267== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==27267== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==27267== Command: ../bin/LINKS_debug
==27267==
==27267==
==27267== HEAP SUMMARY:
==27267== in use at exit: 495 bytes in 6 blocks
==27267== total heap usage: 47 allocs, 41 frees, 463,031 bytes allocated
==27267==
==27267== 8 bytes in 1 blocks are still reachable in loss record 1 of 6
==27267== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27267== by 0x504CA98: gomp_malloc (alloc.c:37)
==27267== by 0x505BA56: gomp_init_num_threads (proc.c:91)
==27267== by 0x504B06A: initialize_env (env.c:1244)
==27267== by 0x4010732: call_init (dl-init.c:72)
==27267== by 0x4010732: _dl_init (dl-init.c:119)
==27267== by 0x40010C9: ??? (in /lib/x86_64-linux-gnu/ld-2.27.so)
==27267==
==27267== 8 bytes in 1 blocks are still reachable in loss record 2 of 6
==27267== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27267== by 0x152F22: mkl_serv_malloc (in /home/rcarvalho/repos/debug/bin/LINKS_debug)
==27267== by 0x1261B4: mkl_sparse_d_create_coo_i4_avx2 (in /home/rcarvalho/repos/debug/bin/LINKS_debug)
==27267== by 0x112AF8: MAIN__ (main.f90:49)
==27267== by 0x112C07: main (main.f90:31)
==27267==
==27267== 32 bytes in 1 blocks are still reachable in loss record 3 of 6
==27267== at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27267== by 0x590C7E4: _dlerror_run (dlerror.c:140)
==27267== by 0x590C050: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==27267== by 0x150F32: mkl_serv_inspector_suppress (in /home/rcarvalho/repos/debug/bin/LINKS_debug)
==27267== by 0x150E8C: mkl_serv_lock (in /home/rcarvalho/repos/debug/bin/LINKS_debug)
==27267== by 0x14EFA1: mkl_serv_cpu_detect (in /home/rcarvalho/repos/debug/bin/LINKS_debug)
==27267== by 0x112EC4: mkl_sparse_d_create_coo_i4 (in /home/rcarvalho/repos/debug/bin/LINKS_debug)
==27267== by 0x112AF8: MAIN__ (main.f90:49)
==27267== by 0x112C07: main (main.f90:31)
==27267==
==27267== 47 bytes in 1 blocks are still reachable in loss record 4 of 6
==27267== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27267== by 0x4017880: _dl_exception_create (dl-exception.c:77)
==27267== by 0x6996250: _dl_signal_error (dl-error-skeleton.c:117)
==27267== by 0x4009812: _dl_map_object (dl-load.c:2384)
==27267== by 0x4014EE3: dl_open_worker (dl-open.c:235)
==27267== by 0x69962DE: _dl_catch_exception (dl-error-skeleton.c:196)
==27267== by 0x40147C9: _dl_open (dl-open.c:605)
==27267== by 0x590BF95: dlopen_doit (dlopen.c:66)
==27267== by 0x69962DE: _dl_catch_exception (dl-error-skeleton.c:196)
==27267== by 0x699636E: _dl_catch_error (dl-error-skeleton.c:215)
==27267== by 0x590C734: _dlerror_run (dlerror.c:162)
==27267== by 0x590C050: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==27267==
==27267== 192 bytes in 1 blocks are still reachable in loss record 5 of 6
==27267== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27267== by 0x504CA98: gomp_malloc (alloc.c:37)
==27267== by 0x5059B65: gomp_get_thread_pool (pool.h:42)
==27267== by 0x5059B65: get_last_team (team.c:146)
==27267== by 0x5059B65: gomp_new_team (team.c:165)
==27267== by 0x5050DDB: GOMP_parallel_start (parallel.c:126)
==27267== by 0x17D0A4: mkl_sparse_d_coo_csr_new_omp_i4 (in /home/rcarvalho/repos/debug/bin/LINKS_debug)
==27267== by 0x17D4A7: mkl_sparse_d_convert_coo_to_csr_i4 (in /home/rcarvalho/repos/debug/bin/LINKS_debug)
==27267== by 0x17D554: mkl_sparse_d_export_csr_data_i4 (in /home/rcarvalho/repos/debug/bin/LINKS_debug)
==27267== by 0x126E68: mkl_sparse_d_convert_csr_i4_avx2 (in /home/rcarvalho/repos/debug/bin/LINKS_debug)
==27267== by 0x112B38: MAIN__ (main.f90:52)
==27267== by 0x112C07: main (main.f90:31)
==27267==
==27267== 208 bytes in 1 blocks are still reachable in loss record 6 of 6
==27267== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27267== by 0x504CA98: gomp_malloc (alloc.c:37)
==27267== by 0x505AFFA: gomp_new_icv (team.c:968)
==27267== by 0x504CF24: omp_set_num_threads (libgomp.h:681)
==27267== by 0x112AB3: MAIN__ (main.f90:47)
==27267== by 0x112C07: main (main.f90:31)
==27267==
==27267== LEAK SUMMARY:
==27267== definitely lost: 0 bytes in 0 blocks
==27267== indirectly lost: 0 bytes in 0 blocks
==27267== possibly lost: 0 bytes in 0 blocks
==27267== still reachable: 495 bytes in 6 blocks
==27267== suppressed: 0 bytes in 0 blocks
==27267==
==27267== For counts of detected and suppressed errors, rerun with: -v
==27267== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
似乎以前也报告过这种问题,正如MKL Sparse BLAS segfault when transposing CSR with 100M rows中所建议的那样,我已经将线程数设置为1,并使用call mkl_free_buffers
子例程。然而,问题仍然存在,在我的一个更大的项目中,这种内存泄漏导致了由于无效写入而导致的程序崩溃。有没有办法解决这个问题?
发布于 2019-06-26 15:17:19
我用最新的2019 u4版本的mkl和用于检查内存泄漏的英特尔检查器工具检查了这个问题。
我将测试编译如下: ifort -g -mkl mkl_spblas.f90 test_memleak.f90运行检查器以获得内存分析,如下所示:mkl_spblas.f90-cl -collect mi1 ./a.out
已开始收集。要停止采集,请按CTRL-C组合键或从另一个控制台窗口输入: /nfs/home/gfedorov/_work/_Stakoverflow/55630336/r000mi1 -cl -r -command -command stop。用于英特尔(R) 64架构应用程序的英特尔(R)数学内核库版本2019.0.4产品内部版本20190411
发现的0新问题
https://stackoverflow.com/questions/55630336
复制相似问题