Analysis failing for too long filenames after upgrading to SonarQube 10.6

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
    SonarQube v10.6 (92116)
    SonarScanner CLI 6.1.0.4477 (via Azure DevOps SonarQubeAnalyze@6 task)
    SonarQube Azure DevOps extension 6.2.0
    Java 17.0.11 Microsoft (64-bit)
    Build Wrapper - downloaded on the fly from SonarQube server - version 6.56 (win-x86-64)
  • how is SonarQube deployed: zip, Docker, Helm
    Helm, running chart version 10.6.1
  • what are you trying to achieve
    Run SonarQube analysis in pipeline
  • what have you tried so far to achieve this
    SonarQube 10.5 worked without issue, even with longer filenames
    Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!

On SonarQube 10.5, analysis completed without issue. Now after upgrading to SonarQube 10.6, getting the following errors:

2024-07-22T15:57:38.1134480Z 15:57:38.109 INFO  850 compilation units analyzed
2024-07-22T15:58:07.9523847Z ##[error]15:58:07.942 ERROR Error during SonarScanner Engine execution
java.lang.IllegalArgumentException: file name 'REDACTED-83-chars/compile_commands.json' is too long ( > 100 bytes)
	at org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.handleLongName(TarArchiveOutputStream.java:500)
	at org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.putArchiveEntry(TarArchiveOutputStream.java:547)
	at com.sonar.cpp.plugin.CFamilySensor.addTarEntry(CFamilySensor.java:367)
	at com.sonar.cpp.plugin.CFamilySensor.addTarEntryIfExisting(CFamilySensor.java:357)
	at com.sonar.cpp.plugin.CFamilySensor.createReproducerArchive(CFamilySensor.java:347)
	at com.sonar.cpp.plugin.CFamilySensor.execute(CFamilySensor.java:190)
	at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:64)
	at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:88)
	at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:64)
	at org.sonar.scanner.scan.SpringModuleScanContainer.doAfterStart(SpringModuleScanContainer.java:82)
	at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:226)
	at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:205)
	at org.sonar.scanner.scan.SpringProjectScanContainer.scan(SpringProjectScanContainer.java:204)
	at org.sonar.scanner.scan.SpringProjectScanContainer.scanRecursively(SpringProjectScanContainer.java:200)
	at org.sonar.scanner.scan.SpringProjectScanContainer.doAfterStart(SpringProjectScanContainer.java:173)
	at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:226)
	at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:205)
	at org.sonar.scanner.bootstrap.SpringScannerContainer.doAfterStart(SpringScannerContainer.java:351)
	at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:226)
	at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:205)
	at org.sonar.scanner.bootstrap.SpringGlobalContainer.doAfterStart(SpringGlobalContainer.java:144)
	at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:226)
	at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:205)
	at org.sonar.scanner.bootstrap.ScannerMain.runScannerEngine(ScannerMain.java:149)
	at org.sonar.scanner.bootstrap.ScannerMain.run(ScannerMain.java:66)
	at org.sonar.scanner.bootstrap.ScannerMain.main(ScannerMain.java:52)

The file folder above is redacted but is 83 characters in length. Total filesystem path length is 145 characters. On the last analysis run we had in SonarQube 10.5, we had even longer paths at at least 155 characters, without any exceptions being issued. The version of Java we are using in pipeline has not changed between SonarQube versions.

Hello @stumt

Seeing this comment

It seems there are two issues. The exception you are seeing happens because the analyzer has crashed (issue 1), the CFamily plugin tried to create a reproducer file and failed because of the long path (issue 2).

The second issue has already been fixed, and the bug fix will be available with SQ 10.7.

The problem can be worked around by disabling the analysis for the file that caused the crash in the first place. You can figure out which file was it by looking for a message like this:

An error occurred while analyzing the following compilation unit:
      <path>

If you add that file to the list of exclusions, the analysis should finish.

This said, it would be interesting to know why did the analyzer crash. Would you be willing to send us by private message the file sonar-cfamily.reproducer that was probably left behind?

1 Like

There were no errors emitted like the following: An error occurred while analyzing the following compilation unit:

There was a warning about not being able to find a standard library include cstring:

2024-07-22T15:57:35.9061677Z The analyzer was not able to find file
2024-07-22T15:57:35.9061852Z   cstring
2024-07-22T15:57:35.9062079Z   included from file C:\azp\agent\_work\1\s\XXXXXX\libs\xxxxxxxxxxxxxxxxxxx\src\Debug.hpp
2024-07-22T15:57:35.9062340Z   included from file C:\azp\agent\_work\1\s\XXXXXX\libs\xxxxxxxxxxxxxxxxxxx\src\Debug.cpp

Hi @stumt, and thanks for taking the time to share the issue with us,

I can conclude that there are two separate problems here:

  1. The cstring header is not found by the analyzer (included from src\Debug.hpp). This may also mean that other standard headers can not be found by the analyzer as well. We log this warning as it usually indicates a configuration issue.
  2. While trying to log the warning, the analyzer hits a recent bug [CPP-5472] - Jira (whose fix will be available in SQ 10.7).

Once 1 is solved, you shouldn’t be impacted by 2 anymore.

To properly understand the reason behind 1, I would need to look at:

  • The full debug analyzer logs (by setting the property sonar.verbose to true).
  • The compile_commands.json file you are using, and information on how you are generating it.
  • There should be a file named sonar-cfamily.reproducer created in your project directory, could you also share this file with us?

I can start a private thread with you if you prefer to share this information in private.

Best regards,
Michael

1 Like

Hi Michael,

Yes please start a private thread.

Thank you

After working with @michael.jabbour, the warnings that were being generated were the result of the compiler probe failing. I’m using the IAR ARM compiler and had not loaded the license during the analysis, which is what caused the probe to fail:

2024-07-23T17:40:33.9835093Z 17:40:33.611 DEBUG Probing compiler: [C:\Program Files\IAR Systems\Build Tools Arm 9.32.1\arm\bin\iccarm.exe, --cpu=Cortex-M0+, --dlib_config, C:\Program Files\IAR Systems\Build Tools Arm 9.32.1\arm\inc\c\DLib_Config_Full.h, --c++, --no_exceptions, --no_rtti, --predef_macros, C:\Users\ContainerAdministrator\AppData\Local\Temp\probe17790258848206668588.tmp, --output, NUL, -]
2024-07-23T17:40:33.9835605Z 17:40:33.698 DEBUG stdout:
2024-07-23T17:40:33.9835856Z  
2024-07-23T17:40:33.9836041Z    IAR ANSI C/C++ Compiler V9.32.1.338/W64 for ARM BX
2024-07-23T17:40:33.9836329Z    Copyright 1999-2022 IAR Systems AB.
2024-07-23T17:40:33.9836503Z 
2024-07-23T17:40:33.9842036Z 17:40:33.698 DEBUG stderr:
2024-07-23T17:40:33.9842492Z  Fatal error[LMS001]: License check failed. Use the IAR License Manager to
2024-07-23T17:40:33.9842819Z           resolve the problem. 
2024-07-23T17:40:33.9843034Z No license found. [LicenseCheck:2.18.3.62,
2024-07-23T17:40:33.9843373Z           RMS:9.7.0.0036, Feature:ARMBX.EW.COMPILER, Version:1.22]
2024-07-23T17:40:33.9843883Z Fatal error detected, aborting.
2024-07-23T17:40:33.9844071Z 
2024-07-23T17:40:33.9844541Z 17:40:33.698 DEBUG probe:
2024-07-23T17:40:33.9844808Z  
2024-07-23T17:40:33.9845191Z 17:40:33.708 DEBUG Probing compiler: [C:\Program Files\IAR Systems\Build Tools Arm 9.32.1\arm\bin\iccarm.exe, --cpu=Cortex-M0+, --dlib_config, C:\Program Files\IAR Systems\Build Tools Arm 9.32.1\arm\inc\c\DLib_Config_Full.h, --predef_macros, C:\Users\ContainerAdministrator\AppData\Local\Temp\probe14395297689720803341.tmp, --output, NUL, -]
2024-07-23T17:40:33.9845673Z 17:40:33.763 DEBUG stdout:
2024-07-23T17:40:33.9845927Z  
2024-07-23T17:40:33.9846100Z    IAR ANSI C/C++ Compiler V9.32.1.338/W64 for ARM BX
2024-07-23T17:40:33.9846400Z    Copyright 1999-2022 IAR Systems AB.
2024-07-23T17:40:33.9846571Z 
2024-07-23T17:40:33.9846776Z 17:40:33.763 DEBUG stderr:
2024-07-23T17:40:33.9847085Z  Fatal error[LMS001]: License check failed. Use the IAR License Manager to
2024-07-23T17:40:33.9847387Z           resolve the problem. 
2024-07-23T17:40:33.9847682Z No license found. [LicenseCheck:2.18.3.62,
2024-07-23T17:40:33.9848016Z           RMS:9.7.0.0036, Feature:ARMBX.EW.COMPILER, Version:1.22]
2024-07-23T17:40:33.9848325Z Fatal error detected, aborting.

This was only seen after enabling verbose output from the sonar scanner, so it might be useful in a future version of the scanner to detect this issue from IAR compilers and bubble it up to at least a warning.

After ensuring the license was loaded, the analysis completed successfully, without generating a reproducer file and thus no longer triggering the reproducer archival bug previously mentioned.

1 Like

Thanks again @stumt for the valuable feedback,

I created a ticket [CPP-5502] - Jira to track work on the logs improvement.

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