LAPACK Archives

[Lapack] Memory management with LAPACKE_dgels - Valgrind validation


Hi Guillaume,

The size of the array B (in input and in output) is LDB-by-NRHS in column major 
format. The array B does not change size.
The size of the array B (in input and in output) is M-by-LDB in row major 
format. The array B does not change size.

Yes, there are memory allocation in LAPACKE (not related to B). We might have a 
reference out-of-bound in LAPACK. I hope not.
Also, please note that sometimes valgrind complains for no really good reason.

Yep, if you come to us with an explanation of the valgrind complain that would 
be very much appreciated.

Cheers,
Julien.

From: Guillaume Jacquenot 
<guillaume.jacquenot@Domain.Removed<mailto:guillaume.jacquenot@Domain.Removed>>
Date: Sunday, September 1, 2013 5:22 AM
To: Julien Langou 
<julien.langou@Domain.Removed<mailto:julien.langou@Domain.Removed>>
Cc: "lapack@Domain.Removed<mailto:lapack@Domain.Removed>" 
<lapack@Domain.Removed<mailto:lapack@Domain.Removed>>
Subject: Re: [Lapack] Memory management with LAPACKE_dgels - Valgrind validation

I hope the code is correct: it is a direct copy from the official Lapacke 
website.
The code gives the correct result, but Valgrind reports memory management error 
on it.
It reports errors with a static allocation of b and also for a dynamic 
allocation of b.
Since the size of b is changing, I would like to know what the code does for 
memory.
I would like to dig this problem, I will try to go down the code, to check all 
memory operation (free, malloc, realloc with eventually the prefix LAPACK_)

Best regards
Guillaume Jacquenot



2013/8/31 Langou, Julien 
<Julien.Langou@Domain.Removed<mailto:Julien.Langou@Domain.Removed>>

Hi Guillaume, so I am looking at your email again, and your code looks correct, 
and it looks like there is a bug on our end. Cheers, Julien.


From: <Langou>, Julien Langou 
<julien.langou@Domain.Removed<mailto:julien.langou@Domain.Removed>>
Date: Saturday, August 31, 2013 12:42 PM
To: Julien Langou 
<julien.langou@Domain.Removed<mailto:julien.langou@Domain.Removed>>, Guillaume 
Jacquenot 
<guillaume.jacquenot@Domain.Removed<mailto:guillaume.jacquenot@Domain.Removed>>,
 "lapack@Domain.Removed<mailto:lapack@Domain.Removed>" 
<lapack@Domain.Removed<mailto:lapack@Domain.Removed>>

Subject: Re: [Lapack] Memory management with LAPACKE_dgels - Valgrind validation


( Oops sorry I am just realizing that you use the ROW_MAJOR flag of LAPACKE. 
Discard my email, please. J. )


From: <Langou>, Julien Langou 
<julien.langou@Domain.Removed<mailto:julien.langou@Domain.Removed>>
Date: Saturday, August 31, 2013 12:39 PM
To: Guillaume Jacquenot 
<guillaume.jacquenot@Domain.Removed<mailto:guillaume.jacquenot@Domain.Removed>>,
 "lapack@Domain.Removed<mailto:lapack@Domain.Removed>" 
<lapack@Domain.Removed<mailto:lapack@Domain.Removed>>
Subject: Re: [Lapack] Memory management with LAPACKE_dgels - Valgrind validation


Hi Guillaume,

LAPACK uses column major format. So if you want A 5-by-3, one way to do it is

double a[15];
   a[0]=1;a[1]=2;a[2]=3;a[3]=3;a[4]=5; /* first column */
a[5]=1;a[6]=3;a[7]=5;a[8]=2;a[9]=4; /* second column */
a[10]=1;a[11]=4;a[12]=2;a[13]=5;a[14]=3; /* third column */

Then you would use m=5; n=3; and lda=5;.
Same thing for your b.

double b[10];
Etc.

And you would need to use ldb=5; as well.

Cheers, Julien.



From: Guillaume Jacquenot 
<guillaume.jacquenot@Domain.Removed<mailto:guillaume.jacquenot@Domain.Removed>>
Date: Thursday, August 29, 2013 2:02 AM
To: "lapack@Domain.Removed<mailto:lapack@Domain.Removed>" 
<lapack@Domain.Removed<mailto:lapack@Domain.Removed>>
Subject: [Lapack] Memory management with LAPACKE_dgels - Valgrind validation

Memory management with LAPACKE_dgels - Valgrind validation

Dear all,

I would like to use the C function LAPACKE_dgels.
I manage to use the example provided on 
[url]http://www.netlib.org/lapack/lapacke.html[/url]<http://www.netlib.org/lapack/lapacke.html%5B/url%5D>
I also manage to use the function with a dynamic allocation of input/output B. 
It works as expected.
However, when I run valgrind on a static or dynamic memory allocation of 
input/output B, valgrind reports errors, such as 'Invalid free() / delete / 
delete[]'

Since the size of output B is different (lower) than the input, I guess the 
function performs memory allocation/deallocation on variable B.
I wonder how memory is handled for this function, and would like some advise to 
use properly the function LAPACKE_dgels with a dynamic allocated input B.
Should one use LAPACK_malloc?

Below is the example provided and the result from valgrind

[code][jacquenot at visu2 demo]$ cat demo_lapacke_dgels.c
#include <stdio.h>
#include <lapacke.h>

int main (int argc, const char * argv[])
{
   double a[5][3] = {1,1,1,2,3,4,3,5,2,4,2,5,5,4,3};
   double b[5][2] = {-10,-3,12,14,14,12,16,16,18,16};
   lapack_int info,m,n,lda,ldb,nrhs;
   int i,j;

   m = 5;
   n = 3;
   nrhs = 2;
   lda = 3;
   ldb = 2;

   info = LAPACKE_dgels(LAPACK_ROW_MAJOR,'N',m,n,nrhs,*a,lda,*b,ldb);

   for(i=0;i<n;i++)
   {
      for(j=0;j<nrhs;j++)
      {
         printf("%lf ",b[i][j]);
      }
      printf("\n");
   }
   return(info);
}


[jacquenot at visu2 Release]$ ./demo_lapacke_dgels
2.000000 1.000000
1.000000 1.000000
1.000000 2.000000
[jacquenot at visu2 Release]$ valgrind ./demo_lapacke_dgels
==5860== Memcheck, a memory error detector
==5860== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==5860== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==5860== Command: ./demo_lapacke_dgels
==5860==
2.000000 1.000000
1.000000 1.000000
1.000000 2.000000
==5860== Invalid free() / delete / delete[]
==5860==    at 0x4A05D21: free (vg_replace_malloc.c:325)
==5860==    by 0x378750ADAA: ??? (in /lib64/libc-2.5.so<http://libc-2.5.so>)
==5860==    by 0x378750A9A1: ??? (in /lib64/libc-2.5.so<http://libc-2.5.so>)
==5860==    by 0x48024E8: _vgnU_freeres (vg_preloaded.c:62)
==5860==    by 0x37874334E4: exit (in /lib64/libc-2.5.so<http://libc-2.5.so>)
==5860==    by 0x378741D99A: (below main) (in 
/lib64/libc-2.5.so<http://libc-2.5.so>)
==5860==  Address 0x5abe0b8 is not stack'd, malloc'd or (recently) free'd
==5860==
==5860==
==5860== HEAP SUMMARY:
==5860==     in use at exit: 0 bytes in 0 blocks
==5860==   total heap usage: 18 allocs, 20 frees, 3,561 bytes allocated
==5860==
==5860== All heap blocks were freed -- no leaks are possible
==5860==
==5860== For counts of detected and suppressed errors, rerun with: -v
==5860== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 4 from 4)
[jacquenot at visu2 Release]$ ./demo_lapacke_dgels
2.000000 1.000000
1.000000 1.000000
1.000000 2.000000
[jacquenot at visu2 Release]$ ldd demo_lapacke_dgels
        linux-vdso.so.1 =>  (0x00007fffd9ffd000)
        liblapacke.so => ./liblapacke.so (0x00002b8a5ebb8000)
        liblapack.so => ./liblapack.so (0x00002b8a5ef6e000)
        libblas.so => ./libblas.so (0x00002b8a5f7fe000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003787400000)
        libtmglib.so => ./libtmglib.so (0x00002b8a5fa6c000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003f0c800000)
        libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00002b8a5fcd3000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003387600000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003787000000)
[/code]


Here is an example of what valgrind reports on dynamic allocated input B
[code][jacquenot at visu2 DEBUG]$ ./run_all_unit_test_tools_math_lapack 
--gtest_filter=ToolsMathLapackTest.dgels005x003
Running main() from gtest_main.cc
Note: Google Test filter = ToolsMathLapackTest.dgels005x003
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from ToolsMathLapackTest
[ RUN      ] ToolsMathLapackTest.dgels005x003
[       OK ] ToolsMathLapackTest.dgels005x003 (0 ms)
[----------] 1 test from ToolsMathLapackTest (0 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (0 ms total)
[  PASSED  ] 1 test.
[jacquenot at visu2 DEBUG]$ valgrind ./run_all_unit_test_tools_math_lapack 
--gtest_filter=ToolsMathLapackTest.dgels005x003
==26590== Memcheck, a memory error detector
==26590== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==26590== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==26590== Command: ./run_all_unit_test_tools_math_lapack 
--gtest_filter=ToolsMathLapackTest.dgels005x003
==26590==
Running main() from gtest_main.cc
Note: Google Test filter = ToolsMathLapackTest.dgels005x003
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from ToolsMathLapackTest
[ RUN      ] ToolsMathLapackTest.dgels005x003
[       OK ] ToolsMathLapackTest.dgels005x003 (109 ms)
[----------] 1 test from ToolsMathLapackTest (132 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (205 ms total)
[  PASSED  ] 1 test.
==26590== Invalid free() / delete / delete[]
==26590==    at 0x4A05D21: free (vg_replace_malloc.c:325)
==26590==    by 0x378750ADAA: ??? (in /lib64/libc-2.5.so<http://libc-2.5.so>)
==26590==    by 0x378750A9A1: ??? (in /lib64/libc-2.5.so<http://libc-2.5.so>)
==26590==    by 0x48024E8: _vgnU_freeres (vg_preloaded.c:62)
==26590==    by 0x37874334E4: exit (in /lib64/libc-2.5.so<http://libc-2.5.so>)
==26590==    by 0x378741D99A: (below main) (in 
/lib64/libc-2.5.so<http://libc-2.5.so>)
==26590==  Address 0x6449b58 is not stack'd, malloc'd or (recently) free'd
==26590==
==26590==
==26590== HEAP SUMMARY:
==26590==     in use at exit: 0 bytes in 0 blocks
==26590==   total heap usage: 358 allocs, 360 frees, 64,566 bytes allocated
==26590==
==26590== All heap blocks were freed -- no leaks are possible
==26590==
==26590== For counts of detected and suppressed errors, rerun with: -v
==26590== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 4 from 4)
[jacquenot at visu2 DEBUG]$
[/code]



Best regards
Guillaume Jacquenot


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.eecs.utk.edu/mailman/private/lapack/attachments/20130901/e130a12c/attachment-0001.html>

<Prev in Thread] Current Thread [Next in Thread>


For additional information you may use the LAPACK/ScaLAPACK Forum.
Or one of the mailing lists, or