LAPACKE_dposv access violation with standard example

[CraigGraham]

I'm maintaining a project that uses the Intel MKL.

In investigating a problem I've gone back to fundamentals and started from a standard example for the LAPACKE_dposv function. I'm using it with the current version (2022.0.1) 64 bit libraries, statically linked, with the appropriate libiomp5md.dll copied to the executable directory to stop it finding a random version in the search path. Aside from fixing a trivial error in the example that was preventing compilation and (after initially discovering this issue) adding code to output the MKL version to make sure I'm using what I think I am, there are no changes from the example.

When run, the example successfully prints the version number but then generates an exception "Access violation reading location 0xFFFFFFFFFFFFFFFF."

I've confirmed that the array pointers to the function are valid. The arrays, set up by the example, contain no NaN or Inf values.

Looking at the stack trace, the exception is being thrown in LAPACKE_dge_nancheck() which is buried within the MKL.

This is in Visual Studio 2019. No MKL extensions have been installed into VS to keep this clean (the original project is using an earlier version). If need be I can zip up the solution folder and put it somewhere but there isn't code I can meaningfully paste. I'm passing no MKL preprocessor directives on the commandline.

Is anyone familiar with this and could give a suggestion as to what may be going wrong?

I've also asked this on Stack Overflow but there's a lack of response so I found this forum.

[VidyalathaB_Intel]

Hi Craig,

Thanks for reaching out to us.

I've tried executing the standard example in VS2019 but I did not encounter the error which you are getting. 

Output:

Could you please show us the screenshot of the output that you are getting? (i tried with oneMKL 2022.0.0, so want to confirm with which version of oneMKL you are working since you have mentioned that you are getting output for MKL version)

Alternately, I suggest you try running the same code from Intel oneAPI command prompt and see if you still see the same error.

You can take the help of the Link line advisor tool which shows you the recommended libraries specific to your use case.

Here is the link:

https://www.intel.com/content/www/us/en/developer/tools/oneapi/onemkl-link-line-advisor.html?wapkw=link%20line%20advisor#gs.zp4m22

I'm also attaching the project file for your reference in case there are any differences in settings.

Please get back to us if you still face the same issue.

Regards,

Vidya.

[CraigGraham]

Sorry for the delay- I've not been getting email notifications.

The problem with the example turned out to be trivial- I'd linked against the libraries correctly, including mkl_intel_ilp64.lib, but I hadn't specified the preprocessor directive MKL_ILP64. Once I did that the access violation exceptions went away and I got the expected result.

[mecej4]

To @CraigGraham : I downloaded the example source from the link that you gave, and ran it on Windows using Intel C 2021.5.0. The program ran and gave the expected output.

You say that you found and fixed a "trivial error". What is that error? When I compiled the source file, I did not see any error messages. It is possible that what you did to "fix" caused an error.

[CraigGraham]

Using Visual Studio 2019 with the language settings at the default C++14, the print_matrix function has to be declared with a const char* instead of a char* in both the function definition and in the declaration at the top of the file. Otherwise compilation fails saying saying you can't pass a const char* (the literal string) to a char* parameter. I assume this is just down to language standards.

[VidyalathaB_Intel]

Hi Craig,

>> I got the expected result

Thanks for the confirmation and glad to know that your issue is resolved.

As the issue got resolved we are closing this thread. Please post a new question if you need any additional information from Intel as this thread will no longer be monitored.

Have a Nice Day!

Regards,

Vidya.