Signalled ACCESS_VIOLATION

I get a strange access violation error.

Please refer to code sections below.

  1. Calling part
SUBROUTINE InitMPIAxNSolver(Core, GroupInfo, ng0, AxSolver, PE)
USE PARAM
USE Typedef,      ONLY : PE_TYPE, CoreInfo_Type, AxFlx_Type, GroupInfo_Type, PE_TYPE
USE P1SENM_MOD,   ONLY : AllocP1AxFlxType
USE SP3SENM_MOD,  ONLY : AllocSP3AxFlxType
IMPLICIT NONE
TYPE(CoreInfo_Type) :: Core
TYPE(GroupInfo_Type) :: GroupInfo
TYPE(PE_TYPE) :: PE
INTEGER :: ng0, AxSolver
INTEGER :: iz, itid

!LOGICAL :: lfirst 
!DATA lfirst / TRUE /
!
!IF(.NOT. lfirst) THEN
!  DEALLOCATE(XS)
!ENDIF
!DATA lfirst  /.false./

ng = ng0; nxy = Core%nxy
nz = PE%nz; nzfm = PE%nzfm
myzb = PE%myzb; myze = PE%myze
myzbf = PE%myzbf; myzef = PE%myzef
SubPlaneMap => Core%SubPlaneMap
!
AxGeom%ng = ng0
AxGeom%ncomp = nzfm; AxGeom%nMesh =nzfm
AxGeom%myzb = 1; AxGeom%myze = nz
AxGeom%myzbf = 1; AxGeom%myzef = nzfm
AxGeom%BC = Core%AxBC
AxGeom%H => Core%Hzfm; AxGeom%HInv => Core%HzfmInv
AxGeom%Comp => Core%SubPlaneMap

CALL AllocMpiAxSol(AxSolver, GroupInfo, ng0, PE)

ALLOCATE(XS(Core%nzfm, PE%nAxThread))
ALLOCATE(FLXOMP(Core%nzfm, PE%nAxThread))
DO itid = 1, PE%nAxThread
  DO iz = 1, Core%nzfm
    IF(AxSolver .EQ. lP1SENM) THEN
      CALL AllocP1AxFlxType(FLXOMP(iz, itid), ng0, .TRUE.)
    ELSEIF(AxSolver .EQ. lP3SENM) THEN
      CALL AllocSp3AxFlxType(FLXOMP(iz, itid), ng0, .TRUE.)
    ENDIF
    CALL AllocPinXS(XS(iz, itid), ng0, 4, GroupInfo%InScatRange)
  ENDDO
ENDDO
!IF(PE%nCmfdProc .EQ. 1) MpiLkg => Lkg


END SUBROUTINE
  1. Called part
SUBROUTINE AllocPinXS(PinXS, ng, nbd, InScatRange)
USE PARAM
USE TYPEDEF, ONLY : PinXs_Type
USE ALLOCS
IMPLICIT NONE
TYPE(PinXs_Type) :: PinXs
INTEGER :: ng, nbd                    !Number of Groups and Number of Boundaries
INTEGER, POINTER :: InScatRange(:, :)
INTEGER :: ig, igb, ige

CALL Dmalloc(PinXS%Dtil, nbd, ng); CALL Dmalloc(PinXs%Dhat, nbd, ng)
CALL Dmalloc(PinXS%atil, nbd, ng); CALL Dmalloc(PinXS%ahat, nbd, ng)   !--- CNJ Edit : Domain Decomposition
CALL Dmalloc(PinXs%PDhat, nbd, ng)
CALL Dmalloc(PinXS%AxDtil, 2, ng); CALL Dmalloc(PinXs%AxDhat, 2, ng)
CALL Dmalloc(PinXS%Dtil2, nbd, ng)
CALL Dmalloc(PinXs%XSD, ng); CALL Dmalloc(PinXs%XSD2, ng); CALL Dmalloc(PinXs%XSA, ng);  !---BYS edit
CALL Dmalloc(PinXs%XST, ng); CALL Dmalloc(PinXs%XSTR, ng)
CALL Dmalloc(PinXs%XSR, ng); CALL Dmalloc(PinXs%XSNF, ng)
CALL Dmalloc(PinXs%XSKF, ng); CALL Dmalloc(PinXs%CHI, ng)
CALL Dmalloc(PInXs%phi, ng); CALL Dmalloc(PInXs%FAC, ng)

ALLOCATE(PinXS%XSS(ng))

PRINT *, UBOUND(InScatRange, DIM = 1), UBOUND(InScatRange, DIM = 2) !--- Signalled ACCESS_VIOLATION

DO ig = 1, ng
  igb = InScatRange(1, ig); ige = InScatRange(2, ig)
  CALL Dmalloc0(PinXs%Xss(ig)%From, igb, ige)
  PinXs%Xss(ig)%ib = igb; PinXs%Xss(ig)%ie = ige
ENDDO

END SUBROUTINE
  1. Type definition
TYPE GroupInfo_Type
  SEQUENCE 
  LOGICAL :: lUpScat, ldum
  INTEGER :: ng, nofg, norg, nchi, ntiso
  INTEGER :: nFxSub, nCatMg
  INTEGER :: UpscatRange(2)
  INTEGER, POINTER :: InScatRange(:, :), OutScatRange(:, :)
  INTEGER :: nGC                 !Number of Condensed Group
  INTEGER :: GCStruct(2,300)     !Coarse Group => Fine Group
  INTEGER :: InvGCStruct(300) !FineGroup => Coarse Group
  
  INTEGER :: nprec = 6
END TYPE
  1. Interface
SUBROUTINE AllocPinXS(PinXS, ng, nbd, InScatRange)
USE PARAM
USE TYPEDEF, ONLY : PinXs_Type
IMPLICIT NONE
TYPE(PinXs_Type) :: PinXs
INTEGER :: ng, nbd
INTEGER, POINTER :: InScatRange(:, :)
END SUBROUTINE

AllocPinXS is successfully called, and the print line correctly prints upper bounds of the array InScatRange.

But then the compiler returns access violation error at the print line.

What am I doing wrong?

If I use

INTEGER :: InScatRange(2, ng)

instead of

INTEGER, POINTER :: InScatRange(:, :)

the code works fine. Isn’t it strange? I’m passing pointer.

Is there a program here to build and execute?

I don’t see how we can help with an execution failure unless we can recreate it.


dave

Entire program consists of more than 220 source files, and I don’t fully understand how they are interconnected.

And the code is protected by copyright.

So I can’t post it, nor send it.

The only issue here is GroupInfo%InScatRange.

Isn’t the information enough?

We certainly understand issues with sharing code, but we do need more
information before determining if you have a bug or pilot error.

What is the definition of TYPE(GroupInfo_Type) ?

Also without knowing what GroupInfo%InScatRange is pointing to, it’s hard to say if the access violation is expected behavior or a bug.

If you can develop a kernel that reproduces this behavior, that is
best case.

Perhaps all that is needed is a definition for GroupInfo_Type (or a scaled down definition) and a main program that calls InitMPIAxNSolver(), etc.

If you can run valgrind, use it to see if there are any memory access errors in their code.

dave