Error finding of Sonar at line 227.
A similiar code fragment in the same file at line 380.
Why doesn’t Sonar recognize the error? Other analysis tools find this error.
Error finding of Sonar at line 227.
A similiar code fragment in the same file at line 380.
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:
sonar.cfamily.reproducer="Full path to the .cpp"
sonar-cfamily-reproducer.zip
in the project folder.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:
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.