3 Replies Latest reply on Mar 24, 2016 5:10 PM by mark_h_@intel

    Insight as to why Valgrind shows memory leak for LAPACKE_dgbsv


      This is the first time I've ever used Intel's MKL LAPACKE and Valgrind. Unfortunately, I get an error with something I have little to no experience with. I could use some advice on how to cure a potential memory leak. I'm using Intel's MKL library, so I highly assume this issue is my fault, but I'm not exactly sure what to look for or how to debug the issue.


      Here is my code (I'm not a programmer)


          int NSUB,NSUPER,NDIAG;

          double *BAND_MX, *SOL;


          NSUB = 3;

          NSUPER = NSUB;

          NDIAG = NSUB + 1 + NSUPER;


          // Intel MKL local variables

          MKL_INT n = 50;

          MKL_INT kl = NSUB;

           MKL_INT ku = NSUPER;

          MKL_INT nrhs = 1;

          MKL_INT lda = 50;

          MKL_INT ldb = 1;

          MKL_INT info;

           MKL_INT *ipiv;


          // Solution array & Banded matrix

          BAND_MX = (double*)calloc(M*(NDIAG+NSUB),sizeof(double));

          SOL = (double*)calloc(M,sizeof(double));


          ipiv = (MKL_INT*)calloc(M,sizeof(MKL_INT));


      Then I add in a bunch of values into `BAND_MX`, which I believe isn't the issue. At the very least, the array would be filled with zeros. So I must be missing something else? Here is my call to the routine, where Valgrind has a breakpoint (line 127).


          info = LAPACKE_dgbsv(LAPACK_ROW_MAJOR, n, kl, ku, nrhs, BAND_MX, lda, ipiv, SOL, ldb );





      Valgrind output:


          Multiple markers at this line

              - 256 bytes in 1 blocks are possibly lost in loss record 5 of 12 [PID: 12922]

              - Line breakpoint: LUx.c [line: 127]

              - 32,928 bytes in 1 blocks are possibly lost in loss record 8 of 12 [PID: 12922]

              - 32,928 bytes in 1 blocks are possibly lost in loss record 7 of 12 [PID: 12922]

              - 80,160 bytes in 1 blocks are possibly lost in loss record 10 of 12 [PID:


              - 69,664 bytes in 1 blocks are possibly lost in loss record 9 of 12 [PID: 12922]

              - 320,160 bytes in 1 blocks are possibly lost in loss record 12 of 12 [PID:


              - 80,160 bytes in 1 blocks are possibly lost in loss record 11 of 12 [PID:



      Is there something that I'm clearly doing wrong? I should also note I'm using eclipse to do this in. I'm more a custom to using Matlab, where I can view the array details while debugging, but I haven't found eclipse to be as user friendly. So again, any advice on how to debug this would be great!


      Here are some more of the details from the log file (just a few of them):


      record 5


          ==14411==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)

          ==14411==    by 0x5899F49: mm_account_ptr_by_tid..0 (in /usr/local/INTEL/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64_lin/libmkl_core.so)

          ==14411==    by 0x5898399: mkl_serv_allocate (in /usr/local/INTEL/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64_lin/libmkl_core.so)

          ==14411==    by 0x51FE053: LAPACKE_dgbsv_work (in /usr/local/INTEL/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64_lin/libmkl_intel_lp64.so)


      record 7


          ==14411==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)

          ==14411==    by 0x5898A3D: mkl_serv_allocate (in /usr/local/INTEL/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64_lin/libmkl_core.so)

          ==14411==    by 0x62A1772: mkl_lapack_xdgbtrf (in /usr/local/INTEL/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64_lin/libmkl_core.so)

          ==14411==    by 0x746F2EA: mkl_lapack_dgbtrf (in /usr/local/INTEL/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64_lin/libmkl_sequential.so)

          ==14411==    by 0x5DA7FF0: mkl_lapack_dgbsv (in /usr/local/INTEL/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64_lin/libmkl_core.so)

          ==14411==    by 0x50CFC92: DGBSV (in /usr/local/INTEL/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64_lin/libmkl_intel_lp64.so)

          ==14411==    by 0x51FE148: LAPACKE_dgbsv_work (in /usr/local/INTEL/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64_lin/libmkl_intel_lp64.so)


      I can post more if need be. Here is my original post on stack overflow: http://stackoverflow.com/questions/36197527/insight-as-to-why-valgrind-shows-memory-leak-for-lapacke-dgbsv


      From what I gathered there, "I'm suspecting the MKL libraries are never released, which causes the MKL-dependant variables to be "possibly lost" but i could be wrong." That being said, I thought I'd reach out to Intel and see if they had any input. I just recently (today) update my student parallel studio package to the latest version (as you can see above in the directory paths). I should note that I'm using Ubuntu 14.04 LTS. I added this to my bashrc file

      source /usr/local/INTEL/parallel_studio_xe_2016.2.062/psxevars.sh

      and in my .profile, I have


           export INTEL_LICENSE_FILE


      Both of these commands I copied from my 2015 version of parallel studio so some things may have changed. Actually, now that I say that, I don't think the file exists (/usr/local/INTEL/licenses) but I don't get any complaints about a license file when trying run it (I have a student version). Is that something I'm suppose to create or add? I didn't see anything about it in the installation instructions. Also, since I work on Ubuntu, I create a file under




      and add the following in the file





      sourcing the following completes the setup (or so I presume)


           source ldconfig


      Also, I should add that I'm using eclipse to run my software. Is there a special way to setup the libraries with eclipse? I simply add the libraries/include paths in the project setup and simply run the program. My program gives me an answer, and everything "seems" to be correct, but I ran Valgrind for the first time and I got the errors listed above. Any insight would be highly appreciated. Thanks!