mkl_?csrgemv provokes access violation

[Lorenzo_B_]

Hello everybody,

I am developing a routine to use the DFGMRES iterative solver. The routine is attached.

Mainly, I call this routine with these variables which are all double precision (INTEGER*8, REAL*8):

      INTEGER, INTENT(IN)  :: nequa, nthre, nrhsi, lusol, symmq
      INTEGER, INTENT(IN)  :: iamat(nequa+1)
      INTEGER, INTENT(IN)  :: jamat(*)
      REAL*8,  INTENT(IN)  :: amatr(*)
      REAL*8,  INTENT(IN)  :: rhsid(nequa)
      REAL*8, INTENT(out)  :: unkno(nequa)      

amatr, iamat and jamat represent the description of the matrix in CSR notation with fortran indexing. In addition I create also the temporal vector tmprl as required in the MKL manual (nequa is the number of rows):

REAL*8  tmprl(nequa*(2*nequa+1)+(nequa*(nequa+9))/2+1)

Then, when performing the following operation:

call mkl_dcsrgemv('n',nequa, amatr, iamat, jamat,tmprl(ipara(22)), tmprl(ipara(23)))

it throws:

Unhandled exception at 0x000000014029f4ae in MyComet64.exe: 0xC0000005: Access violation reading location 0x0000000000000001.

What is happening here? How can I solve it? I am running under Windows 7 with Fortran compiler 11.072 and MKL library 10.1

Thank you in advance!

[mecej4]

We also need the sources containing routines RUNEND and BUILPR, a driver program to call Subroutine SolvGM, and any data file that may be needed to run the program.

[Ying_H_Intel]

HI LB, 

I noticed you mentioned INTEGER *8,  do you link the ilp64 interface?  

What mkl libraries are you using?   Here is MKL link line advisor: https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor

Best Regards,

Ying 

[Lorenzo_B_]

Ying H (Intel) wrote:

HI LB, 

I noticed you mentioned INTEGER *8,  do you link the ilp64 interface?  

What mkl libraries are you using?   Here is MKL link line advisor: https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor

Best Regards,

Ying 

Hi Ying,

I use the ilp64 interface. In fact, I compile linking the following libraries:

mkl_intel_ilp64.lib mkl_intel_thread.lib mkl_core.lib  mkl_solver_ilp64.lib libiomp5mt.lib

Default library directory is set as $(IFortInstallDir)mkl\em64t\lib in compiler options. Do I need to include an interface? Or something else?

[Lorenzo_B_]

mecej4 wrote:

We also need the sources containing routines RUNEND and BUILPR, a driver program to call Subroutine SolvGM, and any data file that may be needed to run the program.

Hi mecej4,

RUNEND is a routine that writes an error message and then stops the program. I am sure that it is not the problem so you can omit that. Instead BUILPR creates a preconditioner matrix. It is attached the routine. The thing is that those routines work and DFGMRES_CHECK returns 0, so data seems to be saved the right way.

EDIT: I forgot to add a driver program that launches SolvGM. Here it is a simplified version of the main program.

[Lorenzo_B_]

Hi again,

first of all, I adjusted the version that I attached. At the moment, as you can see, the code works and the result is correct.

I noticed that the problem is in the definition of the pointers that through the program defines the position of the matrices and vectors in the memory. The memory allocation is done with malloc. The same memory allocation is done when I solve with Pardiso solver, so this is not the problem.

The actual program call to the routine is in fact

call solvgm(%val(p_rof),%val(p_col),%val(p_mat),%val(iwoso), unkno, nequa, 1, 1, 1, .true., 34)

where p_rof, p_col, p_mat and iwoso are the pointers respectively to row vector iamat, columns vector jamat, coefficient matrix amatr and right hand side vector rhsid. However, if I stop before the call of mkl_dcsrgemv while debugging and I recall variables in the watch windows, then they are allocated and with their proper value.

So, is it a pointer problem? How can I check it in VS2008?

[mecej4]

This thread has become somewhat confusing, with multiple program versions.

However, there is a potential problem in Solver.f, where you declare the argument RHSID as INTENT(IN). This is in conflict with the interfaces of DFGMRES and DFGMRES_GET as to intent (INOUT and OUT, respectively). You can detect these mismatches by compiling mkl_rci.f90 and adding "USE mkl_rci" to your subroutine SOLVER.

[Ying_H_Intel]

Hi Lorenzo, 

I'm not sure if it is the function bug in MKL 10.1  or some problem in your real call.  I did a test with the files your provided with MKL 11.1 and 32bit. After fix some compile error like  "The type of the actual argument differs from the type of the dummy argument.   [LUSOL]"

LUSOL some time was integer,  some place is  Logical*1 :: lusol. , the problem can run without any problem. 

I haven't tried ilp64bit.  because In the test case, you haven't define the integer as integer *8.    So not sure where is the root cause, but any way, is it possible for you to try the latest MKL version?   since MKL 10.1 there are many bug fix

Like https://software.intel.com/en-us/articles/intel-mkl-110-bug-fixes

DPD200316016

Fixed mkl_scsrgemv error with one test data on MIC

Best Regards,

Ying 

[Bernard]

>>>Unhandled exception at 0x000000014029f4ae in MyComet64.exe: 0xC0000005: Access violation reading location 0x0000000000000001.

What is happening here? How can I solve it? I am running under Windows 7 with Fortran compiler 11.072 and MKL library 10.1>>>

Coming late to discussion:)

I assume that MyComet64.exe is your application.By looking at error description it seems that this is data access violation.When running under debugger and with source available debugger will be able to pinpoint the exact source code line of the error.

In your case  instruction at this code point 0x000000014029f4ae caused an accesss violation exception.In order to find the possible culprit you should run your app under debugger and break on av exception next step can be backward stack tracing and observing where 0x0000000000000001 address came from.