Possible Heap Corruption after calling DftiCreateDescriptor

[Nightingale__Will]

Hello,

Our application crashes some time after calling DftiCreateDescriptor; we believe because the heap has become corrupt. If we delete the call, the application no longer crashes, or if we reduce the size of the length parameter: also no crash. We are calling it as follows:

static DFTI_DESCRIPTOR_HANDLE dftiHandle128;

DftiCreateDescriptor(&dftiHandle128, DFTI_DOUBLE, DFTI_REAL, 1, 128);
DftiCommitDescriptor(dftiHandle128);

We get no crash if the length parameter is less than 18.

We are running this on an RTOS and link the library in statically. We have noticed this issue after upgrading our compiler from "Intel C++ Compiler XE 12.1" to "Intel C++ Compiler 18.0".

Does anyone know why this might be the case?

Thanks

[Ying_H_Intel]

Hello,

Thank you for post your question, which seems need investigate further.  Do you have small reproduce test case?  Could you submit the problem to https://supporttickets.intel.com/?lang=en-US, where you can upload your test case and the reproduce step so our engineer can look in detail?

By the way, What is the exact of MKL version in later test?  Intel C++ Compiler 18.0​ suppose have MKL 2018 included.

you may add the code before the MKL FFT call .

MKLVersion Version;
mkl_get_version(&Version);
printf("Major version: %d\n",Version.MajorVersion);
printf("Minor version: %d\n",Version.MinorVersion);
printf("Update version: %d\n",Version.UpdateVersion);
printf("Product status: %s\n",Version.ProductStatus);
printf("Build: %s\n",Version.Build);
printf("Platform: %s\n",Version.Platform);
printf("Processor optimization: %s\n",Version.Processor);
printf("================================================================\n");
printf("\n");

Best Regards,

​Ying

[Nightingale__Will]

Hello,

Thanks for getting back to us. We are still working on a smaller example - we haven't been able to yet so there is no ruling out an error elesewhere in our code. When we have one we will submit a support ticket.

The output of your code above is as follows:

Major version: 2018
Minor version: 0
Update version: 1
Product status: Product
Build: 20171007
Platform: 32-bit
Processor optimization: Intel(R) Advanced Vector Extensions 512
(Intel(R) AVX-512) enabled processors
================================================================

Will

[Ying_H_Intel]

Hi Will

​The 32bit platform,  is it possible run with 64bit MKL with the RTOS?

or try sequential MKL, is the application crash?  like export MKL_NUM_THREADS=1  or rebuild the application with sequential libraryyou can find right MKL library by MKL link advisor: Intel® Math Kernel Library Link Line Advisor | …

Best regards,
​Ying

[Nightingale__Will]

Hi Ying,

Unfortunately not as the RTOS is not compatible with 64bit binaries.

We are actually already building with the sequential option.

We did try a previous version of the MKL:

Major version: 11
Minor version: 3
Update version: 4
Product status: Product
Build: 20160823
Platform: 32-bit
Processor optimization: Intel(R) Advanced Vector Extensions 2
(Intel(R) AVX2) enabled processors

Which worked without any issues. (This was still compiled with the Intel C++ Compiler 18.0)

Best regards,

Will

[Ying_H_Intel]

Hi Will,

Thus, MKL 11.3.4 works.  What is your processor type?

the next  candidate

Processor optimization: Intel(R) Advanced Vector Extensions 512
(Intel(R) AVX-512) enabled processors in MKL 11.3.4

vs.

Platform: 32-bit
Processor optimization: Intel(R) Advanced Vector Extensions 512
(Intel(R) AVX-512) enabled processors in MKL 2018 update 1.

Does your RTOS support AVX512? 

May you please try  the code  

mkl_enable_instructions (int isa);

MKL_ENABLE_AVX2

before the version information  and see if it works with MKL 2018 update 1?

Best Regards,

Ying

 

[Nightingale__Will]

Hi Ying,

Unfortunately I am unable to test it today but I think you've hit the nail on the head: The crash actually occurs during restore of FP context, and only affects the newer scalable Xeons. The problem must be with the RTOS not supporting AVX-512 and saving/restoring a context too small.

Thank you very much for the help! Especially as the problem lay with our RTOS and not the MKL.

Best regards,

Will