Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Intel Inspector - Unexplained error

hentall_maccuish__ja
New Contributor II
1,021 Views

Hello,


I was using intel memory inspector to check that there weren't any hidden problems with a project and I got a bunch of uninitialized memory access errors that in the context I don't understand. I managed to create a minimal replicating example below. In this example I get an uninitialized memory access errors on the second read statement, but I don't see what is wrong with this code.


Thanks,

 

    program Test

    implicit none

    ! Variables
    integer :: action    
    integer :: modelChoice

    write (*,*) "Question 1"
    read (*,*) modelChoice
    
    ! Body of Test
    !action = 0
    write (*,*) "Question 2"
    read (*,*) action

    end program Test

 

0 Kudos
1 Solution
Steve_Lionel
Honored Contributor III
994 Views

Intel Inspector generates many false positives for Fortran code - there's nothing wrong with your source. I do find Inspector useful on occasion, but one has to wade through all the noise to find the meaningful messages.

View solution in original post

8 Replies
Steve_Lionel
Honored Contributor III
995 Views

Intel Inspector generates many false positives for Fortran code - there's nothing wrong with your source. I do find Inspector useful on occasion, but one has to wade through all the noise to find the meaningful messages.

hentall_maccuish__ja
New Contributor II
972 Views

Thank you! On one hand that's good, but I would have been happier to learn there was some obscure fixable bug. How do you tell the false positives from the really issues? The fact that Fortran has undefined behavior (for good reasons) means that tools like the inspector to check for undetected bugs seems even more important than in some other languages. Do you have any suggestions as to how to assure that a project is bug free? I’ve had cases where bugs have slipped by undetected even with all the compiler checks on.

0 Kudos
Steve_Lionel
Honored Contributor III
937 Views

Assure a project is bug free? If I knew how to do that, I'd be given the Nobel prize. From my experience with Inspector, focus on issues it has directly in your source file and not in some language library routine that gets called during I/O, etc. It's good about pointer misuse, but has no clue about Fortran semantics.

Inspector is a tool that can help you find issues. Defensive code and testing of edge cases can help. Even though there are languages which are said to allow you to "prove" correctness, all they can do is prove that the program does what you said it should, which might not be what you want it to do.

Arjen_Markus
Honored Contributor I
903 Views

In another context this is known as RMMADWIM - "Read my mind and do what I mean" - https://wiki.tcl-lang.org/page/RMMADWIM.

 

0 Kudos
hentall_maccuish__ja
New Contributor II
895 Views

Hmm. I've tried to asks a variant of this question on this forum before and was also meet with defensive humor. Yes all so called "safe" languages can do is "prove that the program does what you said it should". But that capability already gets me a long way towards being able to be confident that a project is largely correct. Of course the computer can't read your mind but undefined behavior in Fortran means even if you accidently tell the computer to do something completely non-sensical it won't necessarily let you know. I understand the checks in "safe" languages comes at a performance cost, which is why I am using Fortran, but it also seems to me undefined behavior makes tools to check code at the end of a project much more important. If those tools don't work well (e.g. inspector not understanding Fortran semantics or -check uninit still not being implemented on Windows for IFX), this seems like a strong argument in favor of a different high performance language (i.e. C/C++ or Julia). For me personally, it is still not a decisive argument in favor of a different language, but it could become that one day.  

 

@Steve_Lionel  that you for the suggestion and further insight into inspector.

 

@Arjen_Markus nice book by the way.

0 Kudos
Ron_Green
Moderator
925 Views

To add to what Steve said, Intel Inspector is deprecated and will be removed soon.  No meaningful work has been done to it in years. It never really did work with Fortran properly.

 

If you are on Linux and have the 2024.1 compiler, you can use -check uninit.  With caveats.  If you call MKL, or other external libraries, or mixed language C/C++ functions, those have to be built with the LLVM memory santizer.  MKL does not supply such a version, unfortunately.  This capability relies on the memory sanitizer functionality from LLVM.  This is only supported on linux and not Windows. 

 

For the IO functions and other Fortran Runtime functions: we provide 2 full libraries:  normal and one built with memory sanitizer.  The -check uninit or -fsanitize=memory options will cause the driver to link in the appropriate Intel Fortran Runtime library from the 2 choices.  This is how we avoid getting false positives in our IO and other runtime functions. 

hentall_maccuish__ja
New Contributor II
901 Views

Unfortunately I am working on Windows. That leads me to another question I have about IFX vs the classic compiler on windows but that definitely merits another thread

0 Kudos
Steve_Lionel
Honored Contributor III
880 Views

Fortran is a much better choice than C/C++ in this regard (I don't know Julia.) Fortran is strongly typed, and modern Fortran provides many features that allow you to protect against misuse and errors, but the programmer must use them. There are compilers, such as NAG Fortran, that add a variety of run-time checks that most other compilers do not. 

0 Kudos
Reply