Sonar recognizes the same error only once in a file

Error finding of Sonar at line 227.
image

A similiar code fragment in the same file at line 380.
image

Why doesn’t Sonar recognize the error? Other analysis tools find this error.

Hi,

Is this C or C++?

As the docs explain

Once a fatal state of the program is reached, one issue will be raised, and the symbolic execution analysis of the current path will stop

So it’s likely that something between line 227 and line 380 caused a fatal program state.

 
HTH,
Ann

Hi Ann,
it is C.
In the file there is no further error message and no fatal error between these lines,
Other ideas?

Hi,

Thanks for confirming that it’s C. I’ve flagged this for the language experts.

 
Ann

Hello @luj,

The code snippets you shared suggest that this might be code from a header file. This is relevant because header files cannot be analyzed independently. We analyze the translation units (.c, .cpp, …) and the headers these include.

From this assumption, a symbolic execution fatal state could be reached in the currently analyzed source file, leading to no issue being detected on line 380 in the header file.

But this is based on an assumption, and might not be the case.
To investigate what is going on, would you share with me a reproducer for the translation unit causing this, please?

Note that if the issue appears in a header file, you could trace the execution path of the issue appearing at line 227 (first snippet) to see which source file was being analyzed at the time and request a reproducer for that file.

To generate the reproducer file:

  • Search in the analysis log for the full path of the source file for which you want to create a reproducer (for instance, a file that contains a false-positive). You will have to use exactly this name (same case, / or \…)
  • Add the reproducer option to the scanner configuration:
    sonar.cfamily.reproducer="Full path to the .cpp"
  • Re-run the scanner to generate a file named sonar-cfamily-reproducer.zip in the project folder.
  • Please share this file. If you think it contains private information, let us know, and we’ll send you a private message allowing you to send it privately.

Thanks!

Hi Vlad-Andrei,
i have attached the zip file.
Thank you!
sonar-cfamily-reproducer.zip (28.3 KB)

Hello again @luj,

First, I apologize for the delay in getting back to you.

I have investigated the reproducer you attached. While initially, I believed a fatal issue was blocking the other report, this is not the case.

However, there is a more straightforward explanation for why we found the first bug and not the second: Both functions come from a header file, and we do not directly analyze inline functions in a header.

We start our path-sensitive analysis from each function in the current source file. We enter all visible functions, including those in the same source file and inline functions from the headers.

As a consequence, in the issue reproducer you sent me, I observed the following:

  • Both functions are called in a block conditioned by NVIC_isCoreIrq.
  • NVIC_getCoreIrqPrio is called and can return an undefined or garbage value. The condition does not cover all possible switch cases.
  • NVIC_confCoreIrq is also called, but it cannot lead to an undefined or garbage value when called. The condition informs us that the function will return a valid value.

TL; DR - Theoretically, NVIC_confCoreIrq could be called with an out-of-range value and return an undefined or garbage value, but it does not in the current source.

Additionally, if you move these two functions to the source file (which might not be valid in your use case), we will find an issue in both functions. In this case, we would analyze each function independently.

I hope this answers your question. Feel free to elaborate on what else I could help you with.

All the best,

Vlad.

1 Like