Does Intel Fortran compiler support -fsanitize=address like the one for C++?

[Carlygao]

Hi,

I need to detect the memory leakage location or any stack corruption. Does Intel Fortran compiler support -fsanitize=address, or provide any feature to help me to identify the error location? Thanks.

Carly

[Steve_Lionel]

Intel Inspector, a tool that is part of the oneAPI HPC Toolkit, can detect memory leaks. There is /check:stack that can identify some kinds of stack corruption.

[Carlygao]

Hi Steve,

I installed oneAPI HPC Toolkit. Can you give me more details about how to  set up /check:stack? I am using Visual Studio 2019. Thanks.

Carly

[Steve_Lionel]

The best thing to do is build a Debug configuration. This not only enables /check:stack (Fortran > RunTime > Check Stack Frame > Yes, ifort only) but also links in the debug version of the MSVC library that initializes all allocated memory to hex CCCCCCCC and provides some other run-time checks. This may not help for errant writes to otherwise valid stack locations, however.

The way I usually work such issues is to gradually cut out parts of the program - starting with stuff after the error - to find what minimal change results in a different behavior. You might also experiment with compiling some sources with optimization and some without, to see which source affects the issue. (Use binary search to narrow this down.)

[Carlygao]

Hi,

After I turned on al the options mentioned here, I got some more error information. The code immediately crashed in the beginning and triggered the "ntdll.pdb not loaded" page. In the out windows, it complains "'bsam20_2022_09_30_9b502dd.exe' (Win32): Loaded 'C:\Windows\System32\imm32.dll'.

HEAP[bsam20_2022_09_30_9b502dd.exe]: Invalid address specified to RtlValidateHeap( 00000156837E0000, 0000118283DA3380 )
bsam20_2022_09_30_9b502dd.exe has triggered a breakpoint."

Does this mean I have stack corruptions? How should I do next to detect the bug?

BTW, I am using a very big code package mixing Fortran and C++. Thanks.

Carly

 

[Steve_Lionel]

Those DLL messages are not errors or complaints - they're just informational from the debugger telling you which DLLs have debug info and which don't. You should ignore this. Same with the ntdll.pdb message.

You have some sort of corruption - it could be stack or heap (dynamic allocation). What I find interesting in the call stack is that it all seems to go wrong at the program start, perhaps before any of your code executes. I don't see any Fortran frames in there. What happens if you set a breakpoint on the first executable line in the program? If it gets there OK, how far into the code does it get before the error occurs?

If this were a 32-bit application I might be concerned with STDCALL vs. C calling conventions, but I see it is 64-bit where that doesn't apply. 

Do you have a DLL initialization function (DllMain) anywhere in your sources?