Problem with LAPACK subroutine ZHEEVR, input array "isuppz" accessed despite documentation saying otherwise

[Zoë]

Hello, I think I have run into an inconsistency between the documented behaviour of LAPACK subroutine ZHEEVR and the observed behaviour. According to the documentation here: https://software.intel.com/en-us/mkl-developer-reference-fortran-heevr the input array "isuppz" is "eferenced only if eigenvectors are needed (jobz = 'V') and all eigenvalues are needed." However, it appears that the array is accessed even if 1. the "jobz" parameter is 'N' (that is, only the eigenvalues are requested, while the eigenvectors are not); or 2. the "jobz" parameter is 'V', and only a proper subset of eigenvalue/vectors is requested, as specified by the "il" and "iu" parameters. The uploaded files "demos1.f" and "demos2.f" demonstrate these problems respectively. In each demo, the subroutine zheevr() is called on the 6x6 identity matrix. Before the call, the input "isuppz" array is filled with an integer pattern. If the implementation matches the documentation, these initial values should not change upon return from zheevr(). But here, the output shows that the isuppz array did get overwritten by zheevr(). That is, the expected output, for both demo programmes, should be: m: 3 isuppz: 111111 222222 333333 444444 555555 666666 777777 888888 999999 101010 101101 102102 but the actual output was: m: 3 isuppz: 0 0 0 0 0 0 777777 888888 999999 101010 101101 102102 This means that the array may get overwritten when it is not expected to be. In the case when the caller expects isuppz to be not referenced, and therefore passes a small array (maybe to save memory space), the call to zheevr may cause a memory error or buffer overflow. I wish to bring this observation to the attention of the Intel staff here. Thanks! Zoë - Operating system and version -- macOS 10.15.3 - Library version -- MKL 2020.0 (distributed with miniconda) - Compiler version -- gfortran 9.3.0 - Steps to reproduce the error -- The Fortran77 code (attached) was compiled and linked with "-lmkl_rt"

[Polat__Ilhan]

Hi MKL team,

If I am not mistaken this originated from an issue, https://github.com/scipy/scipy/issues/11709, we have on SciPy wrappers. In our codebase we wrapped ?heevr in a way such that when jobz parameter is not "V" we return an empty isuppz array after following the LAPACK reference contract. We also tested this in various platforms using OpenBLAS. After having confirmed test cases we merged into our codebase. But as above, a number of users immediately started getting hit by this behavior.

As far as I could dig in, this relates to how ?stemr interacts with isuppz array depending on the parameters supplied. However as demonstrated above isuppz is referenced regardless. Could you please advice us how we should proceed?

Best,

ilhan

[Sarah_K_Intel]

Thank you for bringing this to our attention, and for the detailed reproducers!  We will take a look into this and let you know the results.

[Polat__Ilhan]

Hi there,

I'd like to kindly ping this issue just in case it fell down between the todo list cracks.

Best,

[Gennady_F_Intel]

Ilhan,

Yes, we investigated and root-caused the issue.

The fix of the issue is planning to be released the next update of mkl 2020 ( update 2). We will keep you informed of the status of this case.

[Gennady_F_Intel]

and plus one more thing, which probably will be useful -  as a workaround the problem, you may try to use ILP64 API instead of lp64.

[Gennady_F_Intel]

the fix of the issue available in MKL 2020 update 2 which has been released and available for download. 

[Polat__Ilhan]

Thank you Gennady F.

Do you mind elaborating what the problem was or how long isuppz array we should allocate to be on the safe side?