CODEWITHSUNDEEP
javalinuxsonarqube
user3808269
user3808269

Reputation: 1351

SonarQube Fails With java.lang.StackOverflowError - How to determine specific file causing error

I am trying to scan some source-code, particularly some Java source files, that fail with java.lang.StackOverflowError. I used my very favourite search engine, Google, to research this some and found some possible solutions.

The best solution I found is here: http://sonarqube-archive.15.x6.nabble.com/StackOverflowException-on-JAVA-AST-analysis-SonarQube-4-5-1-with-java-plugin-2-6-td5030537.html

This solution however does not address explicitly how to a) set the SONAR_RUNNER_OPTS environment variable or b) how to locate the specific file that is causing the error in the first place so one can either 1) exclude it, 2) delete it, or 3) figure out some way to mitigate the the problem so the scan can complete successfully.

My questions are:

  1. How to find out which specific file is causing the error, StackOverflowError in this case
  2. How to set the 'SONAR_RUNNER_OPTS' variable on a Linux operating-system

I have tried to debug the problem in sonar-runner with the -X and -e switches respectively. To run an analysis I use the following command: sonar-runner -X -Dsonar.properties=sonar-project.properties &> debug_dump.txt or sonar-runner -e -Dsonar.properties=sonar-project.properties &> dump.txt. This did not help though.

By the way I am using sonar-runner-2.4.

To set the environment variable SONAR_RUNNER_OPTS I went to the .bash_profile in my $HOME folder and put this entry in it:SONAR_RUNNER_OPTS=" -Xss1600k" Will this actually increase the stack-size for sonar-runner? Also, will I need to restart the operating-system or will the change take effect on the next scan?

Thank-you for reading this post.

Upvotes: 1

Views: 3992

Answers (1)

benzonico
benzonico

Reputation: 10833

Given what you precised in comments, it sounds like you are encountering this bug : https://jira.sonarsource.com/browse/SONARJAVA-1346

As shown in jira ticket it has been fixed in 3.9. So you should upgrade to that version (and thus maybe upgrade SonarQube to latest LTS version (4.5.6 if I'm not mistaking)). Workaround would be to deactivate the rule S2695 while waiting for upgrade.

Upvotes: 1

Related Questions