Help on a detected bug


(dexter) #1

Hi All,

I have enabled the C rule “variables should be initialized before use” and Sonar shows me the following bug:

I don’t understand why the control flow is assuming that i>=num_channels_in at the very beginning the the loop. It deduces that it does not enter the loop and hence pAudioIn_buffer is not initialized. This can’t happen.

We have numerous “bugs” spotted like this.

Could you help me explain this behavior ?


(Loïc Joly) #3

Hello @dextermagnific,

It’s hard to explain anything without having access to the full source code involved in this rule violation (at least all the locations mentioned in the path, as well as the definitions of the involved variables).

What you see could means:

  • That num_channels_in could be negative, and that the loop might indeed be skipped,
  • That the issue happens after the last iteration of the loop, when i has indeed become larger than num_channels_in,
  • That we are in a case where the engine is indeed wrong (symbolic execution-based engines can not be perfect), or just lacks enough information to make the good reasoning,
  • Of something entirely different

Only more details could tell us which of these options is the right one…

(dexter) #4

Thenk you Loïc,

I think the engine thinks num_channels_in could be <=0, so the loop is not entered and the buffer variable never initialized. I’m OK with this analysis.

Now in order to “manage” such kind of issues, could you explain me how the engine performs its analysis.

Let me give you a bit of details on the code.

We have a structure that holds some context:

typedef struct ctx_t {
    int num_ch_in,
    int num_ch_out,

We are doing audio processing, so we basically have the following functions called in that order:

while (there_are_samples_to_process) {

the initAudio() function sets the fields of ctx to good values (here > 0).
the processAudio() function contains the code in which the violation is reported above. At its beginning, it contains:

int num_channels_in = ctx->num_ch_in;

(that’s why I said that it is impossible to not enter the loop).

Could you please tell me how the engine handles such a case: I mean that when analyzing the processAudio() function, does it know that initAudio() has been already called and consequently the fields have good values ?

Now let’s assume that initAudio() and processAudio() are not called inside some sort of main() function in the code itself, but rather passed in a function table to a higher level framework. So initAudio() and processAudio() are not explicitly called. How can we tell Sonar about the order of invocation ?


(Loïc Joly) #5

Hello @dextermagnific,

Currently, the engine only has visibility over one translation unit, which means that if initAudio, processAudio and the function that calls them are in the same file, it can reason on all of them. Otherwise, it cannot, and in this case, the policy is not to report something unless it is pretty sure there is an issue.

This is why I’m not sure your analysis of the issue is right. From my wild guess looking at the screenshot, it might also be related to a relation (or lack of relation) between num_channels_in and num_channels_out. But without more data, it’s just a wild guess, not an analysis.

Maybe a better way to proceed would for you to send me a self-contained reduced program that reproduces this situation, so that we can look at it with more details?

(dexter) #6

Thank you @JolyLoic,

We will take more time to look into the origins of this bug and get back to you if we have news.