Intel Inspector - Unexplained error

[hentall_maccuish__ja]

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

[Steve_Lionel · Accepted solution]

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]

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.

[Steve_Lionel]

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]

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

[hentall_maccuish__ja]

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.

[Ron_Green]

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]

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

[Steve_Lionel]

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.