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 )
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.
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.
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.
REAL,allocatable :: TIMEOFLIMIT(:)
!DEC$ ATTRIBUTES DLLEXPORT::ALLOC
REAL,ALLOCATABLE :: VAR(:)
if( ERR .NE. 0 .OR. .NOT.ALLOCATED(VAR)) THEN
WRITE(NOUT,*)' MEMORY ALLOCATION OF ',NAME,' FAILED ',NUM,' WORDS'
VAR = 0.0
/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
/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.
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.
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).
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.
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.