Hello, I have a code the has a user defined type variable that I added a scalar double precision variable to. After doing this I got the following error "severe (8): Internal consistency check failure" which occurred at a internal write statement that had nothing to do with this variable. When I added another scalar double precision variable to the user defined variable the error went away. My questions are what did adding the variables to the user defined type do to cause the error in the first place, why does this happen and did I really fix my problem or is there still an error that is simple not showing itself. By the way, I did not get any misaligned data warnings when I compiled the code. The code does link to a library that does have a data misalignment warning in it, but that piece of code has never seemed to of given me a problem before or at least until now.
Something in your program is overwriting memory that doesn't belong to it. Your modification of the type shifted memory allocation, causing the error to be revealed. Misalignment itself should not be an issue.
Make sure you have turned on all the run-time checking options. If that doesn't reveal an issue, start commenting out pieces of the program before the WRITE until the error goes away - the last thing you removed is likely the culprit. Intel Inspector XE can sometimes also help identify memory errors.
Steve, thank you for the suggestion. I actual saw that you had made that same suggestion "to comment out the code" in a old post, and following that suggestion is how I found the issue with the user defined variable. I should of mentioned that the variable was an allocatable user defined array variable. Not sure if that make a difference. One of the first thing I did was to turn on all the compiler and runtime error checking available. Currently I am getting no errors and only a few warnings about unused variables, which should not be a problem.
I am running the composer version of the compiler and it does not come with Inspector XE as far as I can tell. It also appears that Inspector XE is not available as a standalone product. The composer version of the compiler is all I could afford at this time. Is there any other way to inspect the memory?
Thank you for your time and help.
I suspect that you've just relocated the corruption into someplace not noticeable.
You can download a 30-day free trial of a Parallel Studio edition that includes Inspector XE, though I'll caution that with Fortran code it usually gives many false-positive warnings. It can take some effort to sift through these to see if anything is actionable, but sometimes it shows a real problem.
I have run my code through the Inspector XE and get the following results
ID Type Sources Modules Object Size State
P1 Kernel resource leak initterm.cpp EngineSimulation Version 2019_V19.exe New
Kernel resource leak initterm.cpp:21 EngineSimulation Version 2019_V19.exe New
P2 Kernel resource leak thread.cpp EngineSimulation Version 2019_V19.exe New
Kernel resource leak thread.cpp:221 EngineSimulation Version 2019_V19.exe New
P3 Memory leak exe_common.inl EngineSimulation Version 2019_V19.exe 48 New
Memory leak exe_common.inl:102 EngineSimulation Version 2019_V19.exe 48 New
P4 Invalid partial memory access Input.f90 EngineSimulation Version 2019_V19.exe New
Invalid partial memory access Input.f90:109 EngineSimulation Version 2019_V19.exe New
P5 Invalid partial memory access Input.f90 EngineSimulation Version 2019_V19.exe New
Invalid partial memory access Input.f90:140 EngineSimulation Version 2019_V19.exe New
P6 Invalid partial memory access Input.f90 EngineSimulation Version 2019_V19.exe New
Invalid partial memory access Input.f90:143 EngineSimulation Version 2019_V19.exe New
P7 Invalid partial memory access Input.f90 EngineSimulation Version 2019_V19.exe New
Invalid partial memory access Input.f90:174 EngineSimulation Version 2019_V19.exe New
P8 Invalid partial memory access Input.f90 EngineSimulation Version 2019_V19.exe New
Invalid partial memory access Input.f90:177 EngineSimulation Version 2019_V19.exe New
P9 Invalid partial memory access MyStop.f90; exe_common.inl EngineSimulation Version 2019_V19.exe New
Invalid partial memory access MyStop.f90:32; exe_common.inl:102 EngineSimulation Version 2019_V19.exe New
P10 Invalid partial memory access exe_common.inl EngineSimulation Version 2019_V19.exe New
Invalid partial memory access exe_common.inl:102 EngineSimulation Version 2019_V19.exe New
P11 Invalid partial memory access initterm.cpp EngineSimulation Version 2019_V19.exe New
Invalid partial memory access initterm.cpp:21 EngineSimulation Version 2019_V19.exe New
P12 Memory not deallocated exe_common.inl EngineSimulation Version 2019_V19.exe 34 New
Memory not deallocated exe_common.inl:102 EngineSimulation Version 2019_V19.exe 34 New
The Invalid partial memory access errors that occur in the subroutine Input.90 are open statements and I can see nothing wrong with them. The error in subroutine MyStop.f90 occurs calling the intrinsic subroutine exit(). When I compile the program I get no errors and no warnings.
Questions are these errors and the kernel and memory leaks being reported by the Inspector XE real or false positives?