Inspector with gfortran and openmp

[Saxena__Akash]

Hi,

I am using a code written in Fortran for academic purposes. I compile the code using gfortran with openmp support. Lately I have been facing strange problems with unexpected behaviour and segmentation faults which do not make sense.

Suspecting the problem to be rooted in memory allocation, I ran Intel Inspector (student license) for both Memory Error Analysis and Threading error analysis, and found lots of errors (screenshots attached). I understand that Inspector can give false positive when testing gfortran openmp codes. Is it possible that Inspector gives false positives to gfortran compiled codes when doing the Memory Error Analysis?

Further, is there a way to buy support from Intel to help me with this? What exact product should i buy?

[Michael_T]

Hi Akash,

Yes, you are correct that Inspector's threading analysis could produce false reports on code that uses non-Intel OpenMP implementation. Most likely it uses custom synchronization primitives and to make it visible to Inspector they should be annotated using ITT API:

https://software.intel.com/en-us/inspector-user-guide-linux-apis-for-custom-synchronization

https://github.com/intel/ittapi

Memory analysis is more reliable in that case, because there are calls to underlying libc function intercepted by Inspector. It is worth to investigate. Also, looking at your picture, I see several invalid memory access problems on string functions (strchr, printf and etc) that could be false reports. Some implementations of those functions read char* pointers by chunks. If string is not aligned to size of that chunk (e.g. size of MMX register), last chunk becomes partially initialized. Technically there will be read of invalid/uninitialized byte reported by Inspector, but logically it is not used because loop stops at ‘\0’ character.

[Saxena__Akash]

Hi Michael, thank you for the guidance.

To remove some of the false flags, I compiled my code intel compilers. However, now when I try to run it through Inspector, I get the following message:

analysis started...
Result file: /home/akash/intel/inspxe/projects/flua/r001mi3/r001mi3.inspxe 
Analysis started for /home/akash/Documents/flua/flua/src/flua_main (pid = 10537) 
Loaded module: /home/akash/Documents/flua/flua/src/flua_main, address range [0x400000-0xbf5587] 
Loaded module: /lib64/ld-linux-x86-64.so.2, address range [0x7f7effdeb000-0x7f7f0001416f], minimal analysis 
Loaded module: [vdso], address range [0x7fff6dd94000-0x7fff6dd9500a] 
Process /home/akash/Documents/flua/flua/src/flua_main exited with code 127. Leak analysis starting. Please wait... 
Unloaded module: /home/akash/Documents/flua/flua/src/flua_main 
Unloaded module: /lib64/ld-linux-x86-64.so.2 
Unloaded module: [vdso] 
Completed analysis for /home/akash/Documents/flua/flua/src/flua_main 
Application exit code: 127 

Result file: /home/akash/intel/inspxe/projects/flua/r001mi3/r001mi3.inspxe 
Analysis completed

When I run it normally, the code fails with a segmentation fault.

I do not understand why this is showing "analysis completed" without even running the code. I have observed this in both Inspector 2019 Update 5 and Inspector 2020.

Am I doing something wrong?

[Michael_T]

Hi Akash,

"analysis completed" means that Inspector checked code executed before process termination. When application is loading modules, there is functionality to actually map those modules in virtual process memory as well as initialization of global objects, runtime libraries initialization and etc. 'some' code is always executed before (and after) your 'main' function.

Talking about that segmentation fail problem. If there is severe memory error Inspector cannot prevent application crash, but there is a chance to capture it as "unhandled exception" problem. If that is the case, you can see its call stack as well as other potentially dangerous problems in Inspector UI. If there is none, then you need to run application under debugger (e.g. GDB) without Inspector and investigate root cause of this problem.