zgeev problem

[Usievich__Boris]

Seems that zgeev routine could write past the end of the rwork array of the recommended size ( 2n ).

here is my code calling zgeev

using namespace std;
#define ComplexD std::complex<double>
bool zeigValVecA(ComplexD *Val, ComplexD *Vec, ComplexD *A, int *n, bool *brk)
{
	char left = 'N', right = 'V';
	int ok(0), LW(-1);

	vector<double> RWORK(size_t(*n)*2); // +1 fixes the access beyond the end of the array inside MKL
	ComplexD work;
	mkl_brk = brk;

	ZGEEV(&left,&right,n,A,n,Val,nullptr,n,Vec,n,&work,&LW,RWORK.data(),&ok);

	if (*brk) return *brk;

	LW=int(work.real());
	vector<ComplexD> WORK(LW);
	
	ZGEEV(&left,&right,n,A,n,Val,nullptr,n,Vec,n,WORK.data(),&LW,RWORK.data(),&ok);
	
	return ok!=0 || *brk;
}

This code resides in a dll statically linked with MKL  and called from a main program written in Delphi. Dll is compiled with the latest Visual Studio 2019. Debugging the the main program I get the following debug output (presumably from VS C++ RTL)

Debug Output: HEAP[ModalCol.exe]:  Process ModalCol.exe (13956)
Debug Output:
Heap block at 000000001525E490 modified at 000000001525F130 past requested size of c90

Offset is beyond the end of the vector storage (n=201). Adding +1 to the RWORK length fixes the problem. The smallest n where i got this behavior is 17.

Tests were made on Windows 10 1909 x64,  Intel Core i9-9900K processor, INTEL_MKL_VERSION 20200000, code is 64bit.

[Gennady_F_Intel]

Boris, this is a known issue and we are planning to fix it into one of the next updates of MKL v.2020. We will keep you informed when this update would be released.

[Usievich__Boris]

Thanks, I suppose that for now my +1 fix is enough?

[Gennady_F_Intel · Accepted solution]

2*n+32 will be better. We will add some detailed instructions about this issue into the coming MKL 2020.1

[Gennady_F_Intel]

the problem has been fixed in mkl v.2020.1

[Usievich__Boris]

Can confirm that the problem has been fixed in 2020.1

[Gennady_F_Intel]

thanks Boris