MKL update 4 protection violation

[Andrew_Smith]

I am attempting to use the latest MKL (update 4) and I find that dspgvx causes protection violation on the second call I make. I added a call to MKL_free_buffers after calling dspgvx and now it protection violates after several hundred calls.

Can you advise me what I need can do to try to isolate a repeatable test case to submit to support?

I will have to go back to update 3 for now but I was also upgrading to Intel Fortran 2011. Can I use MKL update 3 with Intel Fortran 2011 ?

[Andrew_Smith]

I fixed the problem with calling dspgvx by converting my whole exe to pass string lengths after all arguments. It is not something I really wanted to do but it seams to be required by MKL.

With update 3 I had modified the Intel supplied lapack and blass interface source to define passing string lengths at the end but the update 4 overwrote the changes.

I also tried using the pre-compiled blas and lapack modules but they too are not telling the linker how to pass the string lengths properly. I think you should include the correct passing method in your supplied interfaces in future.

Andy

[mecej4]

Are you really calling the Fortran-77 callable MKL-Lapack routine dspgvx from C/C++? Or are you calling the recommended LAPACKE_dspgvx instead?

>I also tried using the pre-compiled blas and lapack modules but they too are not telling the linker how to pass the string lengths properly.

This statement is quite confusing. Fortran modules and object files do not "tell the linker" how to pass arguments.

The old @nn decoration (no longer used as default in Intel Fortran) only checked for the total number of bytes passed; you could still have errors in the individual arguments and, as long the the number of bytes matched, no linker error was caused.

[Gennady_F_Intel]

Andy,

Can you give us the test case, OS, platform?

I did two succesive calls of this routine and the test passed on win64.

--Gennady

[Andrew_Smith]

I am calling dspgvx from the MKL library from Intel Fortan V12. I already mention I was calling from Fortran.

Now that I have converted to string arguments at the end I have now been able to use the f90 generic routine spgvx. I am using mkl95_lapack to get the correct interface. However after two large test runs (each with many eigenvalue solves) I have one run failing with protection violation and the other working well. I will attempt to put together a test case tommorow assuming I can repeat the failure.

I have found that a good practice is to add decoration statements to module interfaces like those in lapack.f90, i.e. !dec$ attributes default :: dspgvx_f95 would define string lengths being passed at the end. Since the supplied lapack.f90 contains no decoration if we use it inside a project with string length passed mixed by default we get wrong interface definitions. I realiize it will be tedious to add this for all of the interfaces in the lapack.f90 module but wouldnt it be a great benefit to prevent users calling routines incorrectly?

By the way I am on Windows XP 64 with a 32 bit application. I also have a 64 bit version which is not having problems.

Andy

[Andrew_Smith]

The protection violation is quite difficult to repeat but I was able to save a set of data that was used during a protection violation. But the simplified test code using this data works fine.

I can get the protection violation to happen repeatedly but in a way I don't expect to happen in normal use.

I am calling mkl from a number of fortran dll's. The fortran dlls are attached to a Smalltalk exe which can load or unload my fortran dlls as required.

If I do an eigenvalue solve using one of my fortran dll's which calls dspgvx and then unload the fortran dll, load it again and re-run the solve I get the protection violation. This does not happen in the older versions of MKL.

Since the mkl dll is attached to other dlls in my exe it should never unload until I close my exe. But it seams like the mkl dll or maybe the threading dll are getting memory corruption somehow after unloading one of my fortran dlls.