Error 408 - attempt to fetch allocatable variable when not allocated

[dajum]

I get this traceback:

forrtl: severe (408): fort: (8): Attempt to fetch from allocatable variable TOL2 when it is not allocated

Image              PC                Routine            Line        Source
libifcoremdd.dll   000007FED45F52A4  Unknown               Unknown  Unknown
UserLogic.dll      000007FECFCB9998  settl                     379  timelist.f
UserLogic.dll      000007FECFC646FD  oper                      304  userLogic.for
astap_16.dll       000007FED1DC1C02  oper                      201  astap.for
astap_16.dll       000007FED1DCF79C  operi                       8  POUTPUT.f
libiomp5md.dll     000007FED07667DC  Unknown               Unknown  Unknown
libiomp5md.dll     000007FED072B067  Unknown               Unknown  Unknown
libiomp5md.dll     000007FED072C4E1  Unknown               Unknown  Unknown
libiomp5md.dll     000007FED06FF4F9  Unknown               Unknown  Unknown
astap_16.dll       000007FED1DCF5FD  operi                       7  POUTPUT.f
astap_16.dll       000007FED1DC1CEC  astap                      25  astap.for
dlltest2008_16.ex  000000013FB118F0  Unknown               Unknown  Unknown
dlltest2008_16.ex  000000013FB1214D  Unknown               Unknown  Unknown
kernel32.dll       0000000077B359BD  Unknown               Unknown  Unknown
ntdll.dll          0000000077C6A2E1  Unknown               Unknown  Unknown

From this routine:

    SUBROUTINE SETTL( NUM )
    USE TIMELIM
    INTEGER NUM,ERR
    external alloc
    call alloc(TIMEOFLIMIT,NUM,'TIMEOFLIMIT','timelist')

Where TIMEOFLIMIT is defined in the module TIMELIM

The alloc subroutine is defined in the same DLL (ProcessModules.dll) that also contains the definition of TIMELIM.  The alloc routine performs the allocation of the variables. 

I have similar calls to this alloc routine from inside the astap_16.dll that work fine.  Not sure why these calls lead to a crash.  Any help as to why this fails would be appreciated.

Dave

[dajum]

oops.  TOL2 should read TIMEOFLIMIT in the message.  Same scenario.

[Steven_L_Intel1]

I note that the error message refers to variable TOL2, which is not in the routine in question.  Where is TOL2? I see also that this is a parallelized application and maybe you have thread safety issues. Which source line is 379? There might be stack corruption issues. 

[dajum]

Line 379 is the call to alloc.  Nothing is happening in parallel here yet in the code.  This is at the beginning before that starts.  I suppose it could be stack corruption, but it doesn't seem likely to me.  I don't understand what the message is suggesting.  Like it is trying to load from the address of the variable, when I think it should just be passing the variable so it can be allocated, like happens in the other calls.  More likely something with being called from different dlls, but I don't know what.

[Steven_L_Intel1]

Please show the declaration of routine alloc and its arguments, and that of TIMEOFLIMIT. Exact compiler version? Compile options?

[dajum]

    module TIMELIM
    REAL,allocatable ::  TIMEOFLIMIT(:)

      SUBROUTINE ALLOC(VAR,NUM,NAME,ROUTINE)
      !DEC$ ATTRIBUTES DLLEXPORT::ALLOC
      use TAPES_MOD
    REAL,ALLOCATABLE :: VAR(:)
    INTEGER NUM,ERR
    CHARACTER*(*) NAME,ROUTINE

    ALLOCATE(VAR(NUM),STAT=ERR)
    if( ERR .NE. 0 .OR. .NOT.ALLOCATED(VAR)) THEN
            WRITE(NOUT,*)' MEMORY ALLOCATION OF ',NAME,' FAILED ',NUM,' WORDS'
        call exit(1)
    ENDIF
    VAR    = 0.0
    RETURN
    END

Compiler options:

/nologo /MP /O2 /fpp /DDPSF /DF90 /DIVF /DSUN /DDOS /DDVF /DQSORT=MSORT /DSTRCMP=MTRCMP /DSTRCPY=MTRCPY /DISNUM=ISANUM /Dstrcmp=mtrcmp /Dstrcpy=mtrcpy /Disnum=isanum /recursive /extend_source:132 /Qopenmp /integer_size:64 /real_size:64 /assume:byterecl /fpe:0 /iface:stdref /iface:mixed_str_len_arg /module:"x64\Release\\" /object:"x64\Release\\" /Fd"x64\Release\vc140.pdb" /traceback /libs:dll /threads /c /names:lowercase  /MP

Linker options:

/OUT:"x64\Release\\ProcessModulesDll_16.dll" /NOLOGO /MANIFEST /MANIFESTFILE:"x64\Release\ProcessModulesDll_16.dll.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /SUBSYSTEM:WINDOWS /IMPLIB:"C:\sf60.git\ProcessModulesDll\x64\Release\ProcessModulesDll_16.lib" /DLL /section:.data,RWS

All dll's and libs use basically the same options. 

This was done using PSXE2016  16.0.0062.14 and VS2015 But I also have it in 11.1.072, but haven't tested for the crash there yet.

We can do a gotomeeting if you would like to do a screen share. 

[Steven_L_Intel1]

I see this is with default optimization. That means there could be inlining going on, if it's in the same source file, and you might not be able to trust the traceback info.  What happens if you use /Od?

I don't see /check:pointer in the options yet I am pretty sure that error is not given unless that is enabled, so it's puzzling.

[dajum]

Well - the traceback came from the optimized version.  But I run it in the debugger and get the same thing.  So the debug version has /Od and it does the same thing.  It won't step into alloc.  I could step through the disassembly version and see what line it is there, but haven't tried that since looking at that code I couldn't really tell what it was doing (not so good at reading assembler anymore).

[Steven_L_Intel1]

Oooh - I just noticed that "external alloc", Bad, bad! Where's the explicit interface for alloc? That's required because VAR is ALLOCATABLE and also assumed-shape. I think that EXTERNAL hides the declaration in the module and creates an implicit interface.  Take it out.

[dajum]

That's it!  Thanks for catching that.  We added the External trying to find it and it didn't change the message.  I have the interface in another module that wasn't being used here.  Adding that fixed it!  So simple, yet it took another pair of eyes to find.  Appreciate the help.