CFamily error reporting issues with cache enabled

SonarQube
1

I found this thread while searching for this specific file pointer problem and wanted to post here to indicate that we’re hitting this issue as well. We have a large C/C++ code base that I am scanning locally on my system. I am employing the cache to speed up the PR scans since fresh scans take quite a while. I am hitting this problem randomly, it seems. There is no concurrency access going on since this is just me running it locally. We’re running developer version right now, 8.9.2 LTS (build 46101) and evaluating purchasing a bigger license to support our plans. I’ve hit this problem at least 5 times now and once I hit it, it’s consistently reproducible. I am open to workarounds or suggests on how we can narrow in on the cause. Is this potentially concurrency related? Can I turn on more debug to provide more info?

I am happy to provide more details over DM too.

3

Hi @michalszelagsonos ,

thank you for your post, I moved it to a new topic. I am sending you a private message where you can share.

4

@michalszelagsonos Have you managed to find the issue ? If you found the cause would you mind sharing how you resolved the issue ? In my ticket CFamily cache is not a valid line for pointer - SonarQube - Sonar Community (sonarsource.com) I just ended up turning the cache off. It runs slower but at least it doesn’t randomly stop working…

5

Hi @michalszelagsonos and @tjnashq ,

we found a case where bad reporting can happen when using the analysis cache, see the related ticket: [CPP-3661] Fix cache crash due to issues reported on invalid line - SonarSource. It involved the analysis of a compilation unit that is using precompiled header and which is containing some code that our frontend is not able to parse correctly (issue with ParsingError/S2260 rule). Does it ring a bell to you?

6

@mpaladin In my case the project that was getting these issues did not have precompiled headers enabled so I don’t think this would be the cause of the issues I was experiencing. But more then happy to try enabling the cache again once 6.33 is available within SonarQube just in case.

7

Not sure but I am looking into this to see if we are using precompiled headers. Looks like 6.33 has some other wrapper improvements related to C++ analysis crash recovery so I am curious to try it and see if this has improved things for us. When can we expect this version to be released?

8

Confirmed that we do not use precompiled header files in our build so our issue is possibly related to something else.

9

Hi @michalszelagsonos and @tjnashq,

We use PCH to speed up the analysis. While we rely on your PCH configuration to deduce what we should precompile, sometimes we precompile files even if you don’t precompile them in your build. For example, if you have one force included header we precompile it.

That is why I would recommend you to renable the cache once you have the fix and let us know if you face the issue again.

Also, you can generate a .reproducer file for the source file on which the exception appear and I can identify if we use a PCH for it. If we confirm that it uses PCH I can share with you privately an internal option to disable the PCH feature and seee if you face the issue again.

Thanks,