MATMUL crash

[Arie_B_]

Dear all,

I have the following subroutine (simplified a bit):

SUBROUTINE OLS(Nobs,Ncov,y,Xin,Xout)

    INTEGER(regInt), INTENT(IN)                                :: Nobs !number of obsevations
    INTEGER(regInt), INTENT(IN)                                :: Ncov !number of regressors 
    REAL(dp), DIMENSION(Nobs,Ncov), INTENT(IN)           :: Xin
    REAL(dp), DIMENSION(Ncov,Ncov), INTENT(OUT)       :: Xout
!
!    !additional variables
    REAL(dp), DIMENSION(Ncov,Nobs)    :: Xtrans

    Xtrans=TRANSPOSE(Xin)
PRINT *,size(Xtrans,1),size(Xtrans,2)  ! prints  53 83434
PRINT *,size(Xin,1),size(X,2)                  ! prints 83434 53
PRINT *,size(Xout,1),size(Xout,2)             ! prints 53 53

    Xout=MATMUL(Xtrans,Xin)

END SUBROUTINE OLS

If I comment out the Xout=MATMUL(Xtrans,Xin) line, the program runs smoothly an the output is as in the comments above. If the MATMUL command is not commented out I get the error message below (and the PRINT commands are not even executed).

(Note: types regInt and dp are defined in another module that is used by the module which contains the above subroutine)

The above compiles and runs without any error using gfortran. Is it a compiler bug? A memory issue?

(The Intel compiler my institution has is named 2018.2.199 on a Linux operating system)

Arie

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
heatCV.x           00000000004281ED  Unknown               Unknown  Unknown
libpthread-2.17.s  00007F09443495E0  Unknown               Unknown  Unknown
heatCV.x           0000000000410016  Unknown               Unknown  Unknown
heatCV.x           000000000040596B  Unknown               Unknown  Unknown
heatCV.x           000000000040301E  Unknown               Unknown  Unknown
libc-2.17.so       00007F0943F98C05  __libc_start_main     Unknown  Unknown
heatCV.x           0000000000402F29  Unknown               Unknown  Unknown
 

[Juergen_R_R]

Your subroutine looks suspicious. The code as written there is no correct syntax, as you define X two times as intent(in) with different shapes. Most likely one is intent(out) and should be XX. You also don't specify what integer parameter regInt actually is. Could it be that the dimensions of your matrix are just exceeding some bounds?

[Arie_B_]

Sorry, I tried to simplify it and made a few mistakes. I edited it and now it reflects my code correctly. (thank you for the quick reply!)

Juergen R. wrote:

Your subroutine looks suspicious. The code as written there is no correct syntax, as you define X two times as intent(in) with different shapes. Most likely one is intent(out) and should be XX. You also don't specify what integer parameter regInt actually is. Could it be that the dimensions of your matrix are just exceeding some bounds?

[Juergen_R_R]

One more remark: why do you explicitly give dimensionalities of matrices as arguments of your subroutine? This could very well be a mismatch of dimensionalities of the argument matrices and the integer arguments which are then used as sizes for the matrices.

[Arie_B_]

The type definitions (in another module):

INTEGER, PARAMETER         :: regInt = selected_int_kind (8)

INTEGER, PARAMETER         :: dp = kind(1.0d0)

[jimdempseyatthecove]

Have you programmed with IMPLICIT NONE and in Debug build with full warnings and full runtime  checks?

Also, stack size may be an issue.

[Arie_B_]

I always put IMPLICIT NONE

I am not familiar with the other part of your question. Sorry. 

I'm running it on a university cluster and submit the jobs remotely.

jimdempseyatthecove (Blackbelt) wrote:

Have you programmed with IMPLICIT NONE and in Debug build with full warnings and full runtime  checks?

Also, stack size may be an issue.

[jimdempseyatthecove]

You can still build with no optimizations, with interface checking, and full runtime checks enabled. If the build fails, you have an interface issue e.g. argument mismatch. If the run fails with a runtime check, the error message will indicate the error. Else if crash it may indicate insufficient stack. For large arrays, make them allocatable.

[Arie_B_]

I spent many hours on it and still can't figure out why would it run perfectly (and give correct results) using gfortran and crashes using Intel Fortran (on the same computer with the same code).

[Juergen_R_R]

Well, we don't see the complete code. So beyond that what jimdempseyatthecove gave as advice there is not much we can do.