dstedc and workspace array

[treq11]

Hi,

I'm running into some errors using the routine dstedc. After querying for the workspace sizes and executing dstedc my program crashes. The c++ code I'm running is basically the following (for several different values of n)

Code: Select all

char type = 'V';
int info;
int n = 30;
double* work = new double[lwork];  // lwork = 3091
double* iwork = new int[liwork];     // liwork = 936
// eVals   - double[n]
// subDiag - double[n-1]
// eVecs   - double[n*n]

dstedc( &type, &n, eVals, subDiag, eVecs, &n, work, &lwork, iwork, &liwork, &info );


If I increase lwork and liwork the routine works properly. This happens with MKL (10.1) as well as the netlib version (3.1). ACML (4.2.0), which doesn't require inputting the workspace sizes, gives a similar error.

Thanks in advance for any help!

[treq11]

Any idea why the problem above happens?

[Julien Langou]

Hello,
I did not have time to check your bug report. I took the time though to add it to the list of Errata of LAPACK-3.2.
See: http://www.netlib.org/lapack/Errata/
Hopefully someone will have time to investigate.
Thanks for reporting this.
Best wishes,
Julien.

[CyLith]

I cannot reproduce this. The code above uses a double (instead of int) pointer for iwork. If that is actually the case in the real code you will get a buffer overflow.

[admin]

We may have found your problem!!!
The fix was committed into the LAPACK repository.
See http://www.netlib.org/lapack/#_svn_access to access it
Julie

[rmjarvis]

I ran across the same problem in MKL with icpc 12.0. I also have the workaround. The recommended size of the lwork is listed as 1+3n+2n*lgn+3n^2. However, this is too low by n^2. The complex varieties get it right, since they have the same recommendation for lrwork, plus an additional n^2 in lwork. For real varieties, the right value is the sum of these two: 1+3n+2*lgn+4n^2. So the bug is that a workspace query returns the wrong value in work[0]. And also that a non-query doesn't check for the right value. Presumably that is what Julie is reporting as fixed, but until the fix makes its way into things like MKL and ACML, hopefully this post will help people who may be searching for a solution.

[zotkevich]

Intel® MKL documentation contains the fix already. See http://software.intel.com/sites/product ... /index.htm for details.