- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Tags:
- CC++
- Debugging
- Development Tools
- Fortran
- Intel® Inspector
- Optimization
- Parallel Computing
- Vectorization
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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: 127Result 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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
![](/skins/images/7FC17B7B85029576C25F1E43CE255B51/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page