topic Re: Heap Corruption and crash when calling pardiso in Intel® oneAPI Math Kernel Library

Heap Corruption and crash when calling pardiso

mostlyAtNight — Mon, 23 Jun 2008 21:53:55 GMT

Hello,

I have hopefully linked pardiso correctly to my application? When I call pardiso (with phase=12) in the debug configuration, I recieve a debug error:

Microsoft Visual C++ Debug Library

Debug Error!

Program: c:lala...

HEAP CORRUPTION DETECTED: before Normal block (#0) at 0x02150FD0.

CRT detected that the application wrote to memory before the start of heap buffer.

I am guessing that pardiso is somehow writing where is shouldn't be in memory?

Has anybody seen this before? :<

Any help / suggestions would be greatly appreciated.

Regards,

Pete

Re: Heap Corruption and crash when calling pardiso

Alemdar__Bulent — Mon, 23 Jun 2008 23:02:14 GMT

Pete

I would suggest you first copy the PARDISO example in the manual into your program, and run your program with it. If you don't see any crash, then you may check the vectorsarrays you are passing into PARDISO in your code (for CC++ array index starts with 0. but for fortran it starts from 1)

bulent

Re: Heap Corruption and crash when calling pardiso

Todd_R_Intel — Tue, 24 Jun 2008 05:40:47 GMT

Bulent makes a good point. PARDISO uses 1-based indexing in it's data structures.
-Todd

Re: Heap Corruption and crash when calling pardiso

mostlyAtNight — Tue, 24 Jun 2008 09:00:20 GMT

Hi there,

Thank you both for your suggestions.

The program I am trying to integrate Pardiso with is written in Fortran so should also have indexes starting at 1. I will make some kind of testing subroutine and copy in the example from the Pardiso manual. Hopefully this will validate that I am calling Pardiso correctly.

I'll let you know how it goes.

Regards,

Pete

Re: Heap Corruption and crash when calling pardiso

mostlyAtNight — Wed, 25 Jun 2008 11:47:51 GMT

Hi there,

I took your advice and put the example included in the manual into a subroutine. The example runs fine.

I thought that the problem (Heap corruption) may show itself if I changed the example arrays to dynamically allocated arrays (located on the stack) rather than statically defined (on the heap). The example still worked.

I then included the line "use matrix_data" to let me have access to the arrays containing the actual data I want to solve in my application.

I then copied the line with the first call to Pardiso and replaced the references to nDiag, aDiag, iaDiag and jaDiag with references to the matrix I have been having problems with. When I debug the program, the first call to Pardiso using the example data works fine, however, the second line still generates a HEAP CORRUPTION error.

Please see a copy of the source code and actual matrix data (attached). I have combined both files which are written out.

I am pretty stumped as the data seems fine, I seem to have referenced everything correctly and the example is working. :<

Does anyone have any suggestions to why this is not working? Could it be something to do with calling conventions? It's currently set to "Default". I am using IVF 10.1

Regards,

Pete

subroutine diagnosePSolveRealData
  
    use program_flow_utilities
    use MKL_PARDISO
    use matrix_data
        
    ! INTEGER*8 ptDiag(64)
    TYPE(MKL_PARDISO_HANDLE), pointer :: ptDiag(:) => null()
    integer, pointer :: idumDiag(:) => null()
    real(KIND=8), pointer :: ddumDiag(:) => null()
    INTEGER maxfctDiag, mnumDiag, mtypeDiag, phaseDiag, nDiag, nrhsDiag, errorDiag, msglvlDiag, intTemp
    INTEGER iparmDiag(64)
    INTEGER iaDiag(6)
    INTEGER jaDiag(13)
    REAL*8 aDiag(13)
    REAL*8 bDiag(5)
    REAL*8 xDiag(5)
    INTEGER iDiag
    REAL*8 waltime1Diag, waltime2Diag, doubleTemp
    
    DATA nDiag /5/, nrhsDiag /1/, maxfctDiag /1/, mnumDiag /1/
    DATA iaDiag /1,4,6,9,12,14/
    DATA jaDiag /1,2,4,1,2,3,4,5,1,3,4,2,5/
    DATA aDiag /1.d0, -1.d0, -3.d0, -2.d0, 5.d0, 4.d0, 6.d0, 4.d0, -4.d0, 2.d0, 7.d0, 8.d0, -5.d0/
    
    integer omp_get_max_threadsDiag
    external omp_get_max_threadsDiag
    
    do iDiag = 1, 64
      iparmDiag(iDiag) = 0
    end do
    
    iparmDiag(1) = 0 ! solver default
    iparmDiag(3) = 2
    
    !iparmDiag(1) = 1 ! no solver default
    !iparmDiag(2) = 2 ! fill-in reordering from METIS
    !! iparmDiag(3) = mkl_get_max_threads() ! numbers of processors, value of MKL_NUM_THREADS
    !iparmDiag(3) = 2
    !iparmDiag(4) = 0 ! no iterative-direct algorithm
    !iparmDiag(5) = 0 ! no user fill-in reducing permutation
    !iparmDiag(6) = 0 ! =0 solution on the first n compoments of x
    !iparmDiag(7) = 0 ! not in use
    !iparmDiag(8) = 9 ! numbers of i
    !iparmDiag(9) = 0 ! not in use
    !iparmDiag(10) = 13 ! perturbe the pivot elements with 1E-13
    !iparmDiag(11) = 1 ! use nonsymmetric permutation and scaling MPS
    !iparmDiag(12) = 0 ! not in use
    !iparmDiag(13) = 0 ! not in use
    !iparmDiag(14) = 0 ! Output: number of perturbed pivots
    !iparmDiag(15) = 0 ! not in use
    !iparmDiag(16) =
 0 ! not in use
    !iparmDiag(17) = 0 ! not in use
    !iparmDiag(18) = -1 ! Output: number of nonzeros in the factor LU
    !iparmDiag(19) = -1 ! Output: Mflops for LU factorization
    !iparmDiag(20) = 0 ! Output: Numbers of CG Iterations
    errorDiag = 0 ! initialize error flag
    msglvlDiag = 1 ! print statistical information
    mtypeDiag = 11 ! real unsymmetric
    
    !do iDiag = 1, 64
    !  ptDiag(i) = 0
    !end do
    
    allocate( ptDiag(64), idumDiag(0), ddumDiag(0), stat=istat )
    call check_allocate_status(istat)
    
    do iDiag = 1, 64
      ptDiag(iDiag)%DUMMY = 0
    end do
    
    ! iz contains the number of non zeros in the matrix
    ivect( (iv+1) ) = iz + 1
    
    phaseDiag = 11 ! only reordering and symbolic factorization
    
    ! Let's open a file and dump the matrix and other crap
    open (unit = 137, file = "c:!Tempmatrix_info.debug")
      write (137,*) "ptDiag : ", ptDiag
      write (137,*) "maxfctDiag : ", maxfctDiag
      write (137,*) "mnumDiag : ", mnumDiag
      write (137,*) "mtypeDiag : ", mtypeDiag
      write (137,*) "phaseDiag : ", phaseDiag
      write (137,*) "iv : ", iv
      write (137,*) "nrhsDiag : ", nrhsDiag
    close(137)
    
    open (unit = 137, file = "c:!Tempmatrices.csv")
      
      write (137,*) ","
      write (137,*) "aDiag"
      do iDiag = 1, iz
        write (137,*) aDouble(iDiag)
      end do
      
      write (137,*) ","
      write (137,*) "jvect"
      do iDiag = 1, iz
        write (137,*) jvect(iDiag)
      end do
      
      write (137,*) ","
      write (137,*) "ivect"
      do iDiag = 1, (iv+1)
        write (137,*) ivect(iDiag)
      end do
      
    close(137)
    
    CALL pardiso (ptDiag, maxfctDiag, mnumDiag, mtypeDiag, phaseDiag, nDiag, aDiag, iaDiag, jaDiag, idumDiag, nrhsDiag, iparmDiag, msglvlDiag, ddumDiag, ddumDiag, errorDiag)
    CALL pardiso (ptDiag, maxfctDiag, mnumDiag, mtypeDiag, phaseDiag, iv, aDouble, ivect, jvect, idumDiag, nrhsDiag, iparmDiag, msglvlDiag, ddumDiag, ddumDiag, errorDiag)
    
  end subroutine diagnosePSolveRealData

Re: Heap Corruption and crash when calling pardiso

mostlyAtNight — Wed, 25 Jun 2008 13:57:05 GMT

Hello!

I have managed to get a small standalone program running which demonstates this HEAP CORRUPTION. The solution files (Visual Studio 2005) are attached as well as a binary file containing the matrix itself. I manage to get a small ammount of output from Pardiso after the HEAP CORRUPTION. This is shown below:

Starting...
*** error PARDISO ( reordering_phase) error_num= -180
*** error pardiso: reordering, symb. factorization

================ PARDISO: solving a real nonsymmetric system ================

Summary PARDISO: ( reorder to reorder )
================

Times:
======

Time fulladj: 0.000076 s
Time reorder: 1.602580 s
Time symbfct: 0.000112 s
Time malloc : -0.496202 s
Time total : 1.106669 s total - sum: 0.000102 s

Statistics:
===========
< Parallel Direct Factorization with #processors: > 2
< Numerical Factorization with BLAS3 and O(n) synchronization >

< Linear system Ax = b>
#equations: 818
#non-zeros in A: 2618
non-zeros in A (%): 0.391258
#right-hand sides: 1

< Factors L and U >
#columns for each panel: 96
#independent subgraphs: 0
< Preprocessing with state of the art partitioning metis>
#supernodes: 688
size of largest supernode:& nbsp; 10
number of nonzeros in L 3921
number of nonzeros in U 2747
number of nonzeros in L+U 6668

Does anyone have any ideas what's causing the HEAP CORRUPTION?

Regards,

Pete

Re: Heap Corruption and crash when calling pardiso

Sergey_P_Intel2 — Fri, 27 Jun 2008 05:35:12 GMT

Hello, Pete!

PARDISO used compressed sparserow formatwhere array ja(*) contains column indices of sparse matrix A. The indices in each row must be sorted in increasing order (see PARDISO documentation).Our matrix checker reported the following error:

*** Error (incorrect input matrix) error_num= 24
*** Input check: j=2617, ja(j)=689, ja(j+1)=405 are incompatible

Please check your matrix format. Probably it is the basis of your problem.

Best regards,

Sergey

Re: Heap Corruption and crash when calling pardiso

mostlyAtNight — Mon, 30 Jun 2008 21:09:13 GMT

Hi Sergey,

Thanks for your reply, I had assumed that the existing solver in the code I am working on was also picky about having column indices in increasing order and therefore assumed they were being written in correctly.

After a few other changes with libraries, it's working nicely now.

Thanks again,

Kind regards,

Pete