Can user defined types cause severe (8): Internal consistency check failure

[Roberts__Raymond]

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.

Thanks

[Steve_Lionel]

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.

[Roberts__Raymond]

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.

[Steve_Lionel]

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.

[Roberts__Raymond]

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? 

Thank you!

[Steve_Lionel]

I think all those can be ignored.

[Roberts__Raymond]

Thank you