- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
oops. TOL2 should read TIMEOFLIMIT in the message. Same scenario.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please show the declaration of routine alloc and its arguments, and that of TIMEOFLIMIT. Exact compiler version? Compile options?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page