Running SonarQube gradle plugin version 6.0.0.5145 with Gradle 8.11 and JDK 21.
The Gradle task has started to produce the following errors:
[stderr] Exception in thread "main" java.lang.StackOverflowError
[stderr] at java.base/java.util.HashMap.putVal(Unknown Source)
[stderr] at java.base/java.util.HashMap.put(Unknown Source)
[stderr] at java.base/java.util.HashSet.add(Unknown Source)
[stderr] at com.sonarsource.A.A.W.A(na:2207)
[stderr] at com.sonarsource.A.A.W.A(na:1627)
[stderr] at com.sonarsource.A.A.W.A(na:1627)
[stderr] at com.sonarsource.A.A.W.A(na:1627)
[stderr] at com.sonarsource.A.A.W.A(na:1627)
[stderr] at com.sonarsource.A.A.W.A(na:1627)
[stderr] at com.sonarsource.A.A.W.A(na:1627)
Thank you for reporting this issue!
We have identified the problem and are working on a fix.
In the meantime, to prevent the crash, you have the option to exclude the file that triggers the issue.
For your project, it should be sufficient to exclude the file support/cas-server-support-gcp-logging/src/main/java/org/apereo/cas/logging/GoogleCloudAppender.java.
I.e. in your build.gradle file, you would have to adapt the sonar section as follows:
Alternatively, if you would like to make sure that the issue will not arise on any new files, you also have the option to completely disable the advanced bug detection analyzer until we release the fix.
You can do this with the following property configuration:
If you are curious about the cause of the crash:
It is related to the use of Lombok, specifically lombok.val. In specific cases, lombok.val is accidentally modeled as a type that is a sub-type of itself.
This then leads to an infinite recursion.
Thank you very much, Anton. Appreciate you looking into the problem. I’ll incorporate your suggestions for the time being and look forward to the fix when it’s available.
We have got the same error with sonar-maven-plugin:5.0.0.4389.
currently, we have also used the workaround to skip the bug detection analyzer to make the build pass. -Dsonar.internal.analysis.dbd=false
Unfortunately, in this case, exactly determining the file that triggers the crash of the analysis is not possible using just the log. However, I can confirm that this appears to be the same underlying problem.
If the source code for your project is available, I can try to pinpoint the file for exclusion as I did in the case above.
Otherwise, setting the sonar.internal.analysis.dbd property is the only solution for now, until the fix is released.
The fix has been implemented, but it is still under review and validation.
The hotfix should now be deployed to SonarQube Cloud and the issue should thus be resolved for SonarQube Cloud users.
(There will still be an error log line about oddities in the type information. However, the analysis will correct it, and safely continue)
Please let me know if you run into any other issues.