Analysis is failing with CFamily plugin version 6.35.0.50389

I’m using SonarCloud. My builds run on Windows 10. It is a Visual Studio C++ 2019 and C# .NET 4.8 project.

It was running fine until one or two days ago.
The last successful analysis, on July 4, reported CFamily plugin version 6.34.0.48468.
The first failed analysis, also on July 4, reported CFamily plugin version 6.35.0.50389.

The failure seems to be related to the CFamily update, not to my code changes. I have verified this by executing the analysis on multiple revisions of my code.

How might I be able to track down the cause of the issue?

Every thread fails with this error message:

ERROR: Exception in thread pool-5-thread-6
java.nio.file.InvalidPathException: Illegal char <<> at index 0: <built-in>
        at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
        at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
        at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
        at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
        at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229)
        at java.base/java.nio.file.Path.of(Path.java:147)
        at com.sonar.cpp.jni.FileSystemOperations.realPath(FileSystemOperations.java:42)
        at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1224)
        at com.sonar.cpp.fs.CanonicalPathCache.computeIfAbsent(CanonicalPathCache.java:17)
        at com.sonar.cpp.plugin.CFamilySensor.canonicalizeFilename(CFamilySensor.java:1072)
        at com.sonar.cpp.plugin.CFamilySensor.save(CFamilySensor.java:971)
        at com.sonar.cpp.plugin.CFamilySensor.lambda$process$19(CFamilySensor.java:917)
        at com.sonar.cpp.analyzer.AnalysisExecutor.lambda$submit$0(AnalysisExecutor.java:59)
        at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
        at java.base/java.lang.Thread.run(Thread.java:832)

Hello @Ben_Ernst,

Can you share the reproducer of the file we are failing to analyze?

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 in the project folder.
  • Please share this file. If you think this file contains private information, let us know, and we’ll send you a private message that will allow you to send it privately.

(optional): in case of an issue in a header file you want to generate the reproducer of the source file that includes that header.

Thanks,

Thanks Abbas I have generated the reproducer. Please send me the PM to share the file privately.

1 Like

I received your PM and I have uploaded the reproducer.

@Ben_Ernst, I received the reproducer thanks.

In your repo, we aren’t finding #include "stdafx.h" that you are force including using /FIstdafx.h"

This file not found started to cause the crash due to a recent change in 6.35 that elevated the analysis warning to a crash when the force included file is not found. We are working on fixing it in CPP-3745.

Nonetheless, if you fix the “file not found” issue the analysis will be much more accurate and the analysis will succeed. So let’s try to do that.

We aren’t finding #include "stdafx.h" due to CPP-3447. Your project compiles when using PCH but fails to find the actual header when PCH is turned off. To fix that should you add the directory of stdafx.h to your include directories?
For example, Let’s say that core\a.cpp analysis is failing. It is force including stdafx.h but there is no stdafx.h in core and nor in the current search directory. Adding the directory of stdafx.h in the search directory should make the analyzer able to find stdafx.h and fix the crash.

Let me know if you need more details,

Thank you for the guidance. We will proceed as you suggest. What you’re saying is consistent with what I’m seeing.

Great, the ticket to avoid the crash is done and should be deployed on SonarCloud in ~3 weeks.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.