java.lang.IllegalStateException at com.sonar.cpp.jni.FileSystemOperations.realPath

Must-share information (formatted with Markdown):

  • Versions: SonarQube 8.9.9 Developer Edition,
  • CFamily
  • Scanner CLI,

After the upgrade to 8.9.9 LTS, we get the following error with one of our C++ source files:

**14:13:25** ERROR: Exception in thread pool-3-thread-1
**14:13:25** java.lang.IllegalStateException: F:/Build/workspace/TestFolder/Test_SonarFerdinand/Implementatie/RbcFederate/include/LinkingInfoCollector.h. 
**14:13:25** at com.sonar.cpp.jni.FileSystemOperations.realPath( 
**14:13:25** at com.sonar.cpp.plugin.CFamilySensor.computeCanonicalPath( 
**14:13:25** at java.base/java.util.HashMap.computeIfAbsent(Unknown Source) 
**14:13:25** at 
**14:13:25** at com.sonar.cpp.plugin.CFamilySensor.lambda$process$8( 
**14:13:25** at com.sonar.cpp.analyzer.AnalysisExecutor.lambda$submit$0( 
**14:13:25** at java.base/java.util.concurrent.Executors$ Source) 
**14:13:25** at java.base/ Source) 
**14:13:25** at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) 
**14:13:25** at java.base/java.util.concurrent.ThreadPoolExecutor$ Source) 
**14:13:25** at java.base/ Source)

From another thread on such a topic (At com.sonar.cpp.jni.FileSystemOperations.realPath( - #11 by bonjour), I downloaded GetFinalPathName and this is the result:

C:\Temp\GetFinalPathName>GetFinalPathName.exe f:\build\workspace\TestFolder\Test_SonarFerdinand\Implementatie\RbcFederate\include\LinkingInfoCollector.h

Please advise us. We would like to stay on the LTS for now, but cannot find instructions to upgrade CFamily without upgrading to e.g. SonarQube 9.5.

Thanks in advance!

Hi @jpouwels,

Can you share the full log?

You can see there a dot(.) at the end of the file name. Does the filename actually include dot at the end?

if you grep in your codebase for inkingInfoCollector.h. do you get any match? for example in an include directive? if yes, and the actual filename doesn’t end with a dot can you try to remove it and retrigger the analysis?


Thanks for the hint! I wrongly assumed the . after the filename belonged to the logging line.
We indeed had a #include with a . after the filename in a source code file.

Best regards,

1 Like

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