Community
cancel
Showing results for 
Search instead for 
Did you mean: 
jirina
Beginner
43 Views

Access violation for phase -1 of Pardiso

I am using Pardiso and everything works well except one thing. I noticed that my application keeps increasing the memory usage when Pardiso is repeatedly called. I found in the documentation that I should use the phase -1 to release all internal memory. I am trying to do so, but I am getting a "forrtl: severe(157): Program Exception - access violation" error.

I use the same call to Pardiso, just phase is changed to -1; is this wrong?

 integer(4) :: pt(64) ! Solver internal data address pointer
 integer(4) :: mtype ! Matrix type
 integer(4) :: iparm(64) ! Pass information to and from Pardiso

 integer(4) :: nDimension
 integer(4), parameter :: numberOfRHS = 1 ! number of right-hand sides

 integer(4) :: maxfct, mnum, mtype, phase, error, msglvl
 

 do i=1,64
   pt(i) = 0
 enddo
 
 do i=1,64
   iparm(i) = 0
 end do

 mtype = 11 ! real + nonsymmetric
 
 maxfct = 1 ! maximum number of numerical factorizations
 mnum = 1 ! what factorization to use
 msglvl = 0 ! message level, 0 = no output, 1 = statistical information
 error = 0 ! error flag initialization

 call PardisoInit ( pt, mtype, iparm )

 phase = 13
 call PARDISO ( pt, maxfct, mnum, mtype, phase, nDimension, Avec, iVec, jVec,
+               perm, numberOfRHS, iParm, msglvl, Bmat, Xmat, error )

 phase = -1
 call PARDISO ( pt, maxfct, mnum, mtype, phase, nDimension, Avec, iVec, jVec,
+               perm, numberOfRHS, iParm, msglvl, Bmat, Xmat, error )

Avec(:) is real*8, iVec(:), jVec(:), perm(:) are integer(4), Bmat(:,:) and Xmat(:,:) are real*8, all of them allocatable. I checked that they are initialized. 

Question 1: Any ideas why phase -1 crashes with the access violation error?

Question 2: The first call to Pardiso yield error = 0, so I hope there is nothing wrong about data passed to it. I noticed some people use dummy integers and doubles in places of those arguments that are not needed in particular Pardiso phases; is this acceptable/supported ?

I tried checking MKL cookbook samples, but the example for Pardiso is for C, not Fortran.

 

0 Kudos
13 Replies
jirina
Beginner
43 Views

I created a small example that reads array data from disk, solves the linear system with no error and crashes with the access violation error when memory release is attempted. The example is attached to this post.

mecej4
Black Belt
43 Views

Which version of MKL did you use, and which version of the Intel Fortran compiler? OS version?

I ran your code with an old version of IFort (Version 12.1.0.233) and the associated MKL, and it ran with no errors.

jirina
Beginner
43 Views

I use Intel Parallel Studio XE 2016 Composer Edition Update 4 in Visual Studio 2010 Professional SP1.

I wanted to try the same example in Intel Parallel Studio XE 2017 Composer Edition Update 2 in Visual Studio 2015 Community, but it does not compile due to an internal compiler error. Should I report this in another forum?

1>------ Rebuild All started: Project: Pardiso_Test, Configuration: Debug x64 ------
1>Deleting intermediate files and output files for project 'Pardiso_Test', configuration 'Debug|x64'.
1>Compiling with Intel(R) Visual Fortran Compiler 17.0.2.187 [Intel(R) 64]...
1>solver_matrix_Pardiso.for
1>fortcom: Fatal: There has been an internal compiler error (C0000005).
1>ifort: error #10298: problem during post processing of parallel object compilation
1>compilation aborted for D:\Source_Fortran\VITREOUS\Intel\Pardiso-Reduced - Copy\solver_matrix_Pardiso.for (code 1)
1>pardiso_test.for

The ICE is gone if I remove calls to Pardiso...

How do I find out which version of MKL is used? I guess it is the one associated with the compiler.

OS is Windows 7 Professional SP1 64-bit.

mecej4
Black Belt
43 Views

It seems that you have answered yourself regarding the MKL version, and your code of #2 queries and prints out the MKL version.

I built your example again at the command line, this time on Windows 10 X64 with VS2010 and Parallel Studio 2016U4. As in my earlier test, the program ran with no errors. There must be something specific to your system that is causing a problem.

Regarding the ICE with the 2017U2 compiler, please report in the Fortran compiler forum. Try compiling without /MP (parallel compile).

jirina
Beginner
43 Views

Thank you very much for your trials, even though they are making me desperate as I do not see any direction where to go from here.

Anyone from Intel, would you please try recommending what else I can try to make the simple example work?

mecej4
Black Belt
43 Views

Here is something that may be useful in pinpointing the problem: please recompile and run with (i) optimizations off, and (ii) traceback enabled and /link /map specified. You should get addresses, line numbers and routine names in the traceback. With that additional information, we'll know where the crash occurred. This will take only a few minutes of time, and will be of help to the Intel people when they respond.

jirina
Beginner
43 Views

I am using testing the Debug x64 configuration where /Od and /traceback are already used. The /map linker option generates a file during linking. Regarding the /link option, do you mean I should use it with the /map option?

Anyway, I used the command line to run the Debug x64 configuration executable. I added mkl_avx2.dll, mkl_core.dll, mkl_def.dll and mkl_intel_thread.dll to the folder with the executable; I took them from C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016\windows\redist\intel64_win\mkl. When i run the executable, I get the same output like if I debug the application in Visual Studio:

 Pardiso test
 ============
forrtl: severe (157): Program Exception - access violation
Image              PC                Routine            Line        Source

mkl_core.dll       000007FEC698EDF0  Unknown               Unknown  Unknown
mkl_core.dll       000007FEC66AF4AA  Unknown               Unknown  Unknown
mkl_core.dll       000007FEC67500AE  Unknown               Unknown  Unknown
mkl_core.dll       000007FEC66BE787  Unknown               Unknown  Unknown
Pardiso_Test.exe   000000013F5C2609  MATRIXSOLVERPARDI         179  solver_matri
x_Pardiso.for
Pardiso_Test.exe   000000013F5C4BDE  MAIN__                     15  pardiso_test
.for
Pardiso_Test.exe   000000013F5C70CE  Unknown               Unknown  Unknown
Pardiso_Test.exe   000000013F5C520C  Unknown               Unknown  Unknown
Pardiso_Test.exe   000000013F5C505E  Unknown               Unknown  Unknown
kernel32.dll       0000000076AE59CD  Unknown               Unknown  Unknown
ntdll.dll          0000000076D1A561  Unknown               Unknown  Unknown

mecej4
Black Belt
43 Views

This is probably where all your troubles started: The array PT is supposed to be a "pointer" array for internal use in Pardiso. Each element of PT is 4 or 8 bytes for IA-32, and 8 bytes for Intel-64. In your program, however, you only have INTEGER*4. You have, therefore, an incorrect type and an insufficient memory block allocated for PT.

Note, in addition, that in recent years the recommended type for PT is TYPE(MKL_PARDISO_HANDLE)​ rather than INTEGER*4 or INTEGER*8. If you use this new style declaration for PT, you will also be forced to include MKL_PARDISO.FI or USE the corresponding MKL module, so the length will be correct whether you build for IA-32 or Intel-64.

 

 

 

jirina
Beginner
43 Views

Your are right that the array PT should be a different type.

I changed it to integer(8) in IPS 2016 and I am now able to run the sample code without the access violation error.

I changed the type to integer(8) also in IPS 2017 and I still get the internal compiler error.

I would like to try using TYPE(MKL_PARDISO_HANDLE), but I do not know how.

  • The only information I found in the documentation was that this type exists.I am a beginner, so I am missing information what I have to do to be able to use it. Also, the Pardiso example in the MKL cookbook defines PT as integer(8).
  • I tried using include 'MKL_PARDISO.FI', but there is a problem that this is written in the free form, while I am using the fixed form in my application.
  • Another option you suggested was to USE the corresponding MKL module. How do I find out which one it is? Again, this does not seem to be explained in the documentation or in examples.

I am sorry to keep asking possibly silly questions; I am a beginner, inexperienced in this "advanced" stuff.

Thank you very much for your kind help, tips and advices; I appreciate it.

mecej4
Black Belt
43 Views

There is a file called mkl_pardiso.f90​ in the MKL include directory. If you compile it, the module file mkl_pardiso.mod​ will be created (the module files are specific to IA32 and Intel64, so put the module file into the appropriate directory -- .../mkl/include/ia32 or .../mkl/include/intel64. This only needs to be done once for a given compiler release. Once this is done, you can add USE MKL_PARDISO in your source files in order to have the MKL_PARDISO_HANDLE and other related declarations available.

jirina
Beginner
43 Views

Thank you for your detailed instructions; I will try them soon.

In between, I decided to use integer(8) for the PT array, because it works in the small example.

My current problem is that after correcting the definition of the PT array to integer(8), I still get the access violation error when calling the Pardiso routine with phase=-1.

I am using the same data for A, jA, iA, B and X; the phase 13 works well and error is 0 after it finishes, but while phase -1 finishes with error 0 in the small example, it crashes with the access violation error in the original application. Both small and original application yield the same result X in the phase 13, output from the Pardiso routine is almost identical (completely the same information about arrays, calculation times are slightly different because I use 4 threads).

Since the function solveLinearSystemPardiso is the same in both applications (see the small example) and arrays and settings are the same, I do not know what could be causing the access violation error.

mecej4
Black Belt
43 Views

It is not feasible to read all the posts in this thread and reconstruct the latest version of the source that is still giving you the access error. Bugs (in your code or in MKL or even the OS) are often sensitive to the environment in which they exist. You may think that all the relevant parts are "the same", but there could be side effects elsewhere.

Please post a "reproducer" again, and I'll take a look.

jirina
Beginner
43 Views

I am sorry for not being specific; I agree it is not possible to try resolving any issues then. My apologies.

I think I found the cause of the problem. I was accessing the pt array directly in subroutine initializePardiso ( ). I removed following code from the subroutine

      do i=1,64
        pt(i) = 0
      enddo
      
      do i=1,64
        iparm(i) = 0
      end do

and replaced it by

      mtype = 11
      call PardisoInit ( pt, mtype, iparm )

The call to PardisoInit was then deleted in function solveLinearSystemPardiso ( ) not to have it called twice. I am no longer getting any access violation errors.

I tried one more thing to see how the pt array can be defined. Instead of defining it as integer(8), I added this code

      module PardisoPrivate
      
      type MKL_PARDISO_HANDLE
      integer(kind=8) dummy
      end type
      
      end module PardisoPrivate

and defined the pt array as type(MKL_PARDISO_HANDLE). Functionality remained the same and no errors were issued.

Finally, when trying to save data used by the Pardiso solver, I tried call pardiso_handle_store ( pt, "", error ) right after PardisoInit, and I am getting access violation error. I do not need to save pt, I just came across this while trying to resolve my original problem.