StackOverflowError in SonarCloud When Analyzing Java 21 Code

SonarQube Cloud
1

Dear team,

I encountered a StackOverflowError during SonarCloud’s analysis of a Java 21 project.

The issue can be reproduced using the following minimal Java code example:

public class TestSonar {

    public void test() {
        var response = exchange((a, b) -> {
            if (a != null) {
                return new SuccessResponse();
            } else {
                return new ErrorResponse();
            }
        });
        System.out.println(response);
    }

    <T> T exchange(ExchangeFunction<T> exchangeFunction) {
        return null;
    }

    public interface ExchangeFunction<T> {
        T exchange(String a, String b);
    }

    private sealed interface Response permits SuccessResponse, ErrorResponse {
    }

    private record SuccessResponse() implements Response {
    }

    private record ErrorResponse() implements Response {
    }

    public static void main(String[] args) {
        new TestSonar().test();
    }
}

When this code is analyzed, the following error occurs:

[INFO] Reading IR files from: /opt/src/target/sonar/ir/java
[INFO] Analyzing 4655 functions to detect bugs.
[ERROR] [stderr] Exception in thread "main" java.lang.StackOverflowError
[ERROR] [stderr] 	at com.sonarsource.A.A.W.A(na:885)
[ERROR] [stderr] 	at com.sonarsource.A.A.W.A(na:1627)
[ERROR] [stderr] 	at com.sonarsource.A.A.W.A(na:1627)
... (repeated stack trace omitted for brevity) ...

Please let me know if further information would help resolve this issue.

1 Like
7

Hi Boon Hendrik Kinesso,

thank you for this report, and in particular for this very concise reproducer!

This seems to be another instance of the issue reported here: SonarQube gradle plugin v6 producing StackOverflowError .

We have identified the problem, and have developed measures to prevent the crash.
We are still investigating some aspects of the cyclic type hierarchy that induces the crash, but at least the aforementioned hotfix is under validation now and should be deployed with the next release of the DBD analyzer component.

I will post an update here once this fix has been deployed.

In the meantime, to address your failing analysis task until the fix is deployed, you have two options:

(1) You can disable the crashing analyzer component by setting the sonar.internal.analysis.dbd property to false.

(2) Alternatively, you can employ a more fine grained approach by adding the file that causes the issue to the property sonar.exclusions. It should be the file containing a lambda expression that is similar to the one in your reproducer.

You can find a concrete example of how to define these properties with gradle here.

Please let me know, if you would like help with setting these properties for a different build system (e.g. maven).

1 Like
9

Dear Anton,

Thank you for your quick response! I had indeed already implemented the sonar.exclusions workaround, as Sonar is integrated into our continuous integration pipeline, and this issue was creating a bit of a bottleneck.

It’s great to hear that a fix is in progress. Please keep me updated once the issue is resolved, so I can remove the exclusion and restore the intended setup.

Thanks again for your support!

Best regards,

Hendrik

10

Hi again, Hendrik,

thank you for your patience.

The hotfix should now be deployed to SonarQube Cloud and the issue should thus be resolved for SonarQube Cloud users.
On my end, I can confirm that the reproducer is no longer triggering the issue.
(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.

Best regards,

Anton

1 Like
11

Hi Anton,

I’ve removed the exclusion and can confirm that everything is now working as expected. Thank you for addressing this issue with such high priority—it’s greatly appreciated.

1 Like