Access violation in dss_solve_real

[Maria_B_]

Hello,

We are calling MKL from C# code by using general mechanism described in article Using Intel® MKL in your C# program.

The code is using DSS (Direct Sparse Solver) for a large system of equations with numerous different right-hand sides. That is, it makes one call to dss_factor_real and a lot of subsequent calls to dss_solve_real. Generally it works fine. But sometimes, at an advanced interation, an error ocurrs in dss_solve_real:
        "Attempted to read or write protected memory. This is often an indication that other memory is corrupt."

So far no particular trigger for this error was detected. In the past I have noticed that if a memory allocation occurs after creating internal dss structures (i.e. after dss_factor_real which obviously must take up a lot of space due to LU decomposition), then a subsequent call to a computing dss function will likely cause an error above. And therefore I am careful not to make any explicit allocations when dss handle is in use. But the error still occurs once in a while.
Just in case, threading is disabled by setting MKL_NUM_THREADS=1.

Any help will be greatly appreciated.

[mecej4]

I tried to reproduce the access violation that you described. I have a short Fortran program that reads a NIST Matrix Market RSA file and computes the solution using DSS. I modified the program by placing a loop around the invocation of dss_solve_real(), and tested it by running it on  BCSSTK01, BCSSTK02, BCSSTK13 and BCSSTK14. In each case, the solution was computed 100 times and compared to the known solution. No errors occurred.

I suspect that the error message comes from some C# support component, because none of the MKL DLLs in <Intel Parallel Studio>\compilers_and_libraries_2017.4.210\windows\redist\ia32_win\mkl contains the string "memory is corrupt".

To investigate this problem further, we need from you a reproducer (source code, data files if needed, instructions to build, run and exhibit the claimed error).

[Note: I posted a response earlier, but that note did not appear, so I am trying again].

[Zhen_Z_Intel]

Hi Maria,

The kind of problem may caused by unmanaged code debugging issue and common to see for some C# program. Would you mind share us a simple reproducer with a VS project. We will check with the root cause. Thank you.

Best regards,
Fiona

[Maria_B_]

Thank you, mecej4 and Fiona!

I will try to build one, though it is not an easy task. Apparition of this problem is extremely volatile. It may vanish from such subtle a change as renaming input data file. Not to say porting to another computer. But, of course, reproducing is the only option...  :)

Regards,

Maria

[mecej4]

Yes, an apparition morphing into an occultation is a problem.

If the underlying bug is not an optimizer bug, turning optimizations off may help to nail the apparition down.

If the bug is caused by array overruns or by using variables that have not yet been defined, however, changing optimization options may cause the bug to disappear. If so, much trial and error will be needed during the course of creating a cut-down reproducer.

[Maria_B_]

Hello and sorry for a long pause.

Here is a reproducer VS project in C#.
It can also be launched without running VS: just open a console, change directory to Reproducer\bin\Debug and run the application with a parameter of input data file located in the same folder. For example:

 >Reproducer.exe P_54x78.txt

Some more info in readme.txt. Thank you again.

Maria

[Ying_H_Intel · Accepted solution]

Hi Maria,

We can reproduce the problem, will investigate the details.

On the other hand, we happened to worked another C# issue, which also was proved be C# GC memory problem. Please see

https://software.intel.com/en-us/forums/intel-math-kernel-library/topic/737444

It seems almost same place problem, (Handle internal memory). If possible,  could you please try to change the call interface as below:

[DllImport("mkl_rt.dll", CallingConvention = CallingConvention.Cdecl, ExactSpelling = true, SetLastError = false)]
        internal static extern int dtrnlspbc_init(
           ref IntPtr handle,
           ref int n,
           ref int m,
           IntPtr x,
           IntPtr LW,
           IntPtr UP,
           double[] eps,  ---->  IntPtr eps 
           ref int iter1,
           ref int iter2,
           ref double rs
        );

and  when you define the input parameter ( x, LW, UP , EPS etc) , their pointer were stored in Handle. Please use

IntPtr handle = new IntPtr(0);

IntPtr x = new IntPtr(0);

double[] x = new double;

GCHandle x_handle = GCHandle.Alloc(x_init, GCHandleType.Pinned);
x = x_handle.AddrOfPinnedObject();
//use x pointer …
...
finally 
x_handle.Free();  -> manually collection. 

Best Regards,

Ying

[Maria_B_]

Ying,

I cannot say enough how helpful this was. This completely solved our problem. In fact, since objects in managed code are moved around by the garbage collector, assuming their physical address being constant leads to access violation error. So pinning objects is the solution.

Thank you! And thanks to everyone who was concerned with this matter.

Maria

[Keola_W_Intel]

Hi everyone, please note that we have added a section about memory pinning in C# to the article Using Intel® MKL in your C# program along with some examples for the Direct Sparse Solvers interface and Trust Region Solvers with reverse communication interface. Thanks!