squid:S2275 - java.lang.IndexOutOfBoundsException with latest SonarJava 5.11 plugin

First time reporting a bug, sorry in advance for some missing information.

This error happened after an update made last friday from sonarqube version 7.2 to version 7.5 and the SonarJava plugin 5.6 to the latest version 5.11. During the weekend multiple jobs failed with the error I posted below - IndexOutOfBoundsException

After some research I think this is related with squid:S2275 - Printf-style format strings should not lead to unexpected behavior at runtime.

In the class referred in the log below I found out that the developers had left some String.format() with a mismatch between the args and the params and sonar does something different/new that leads to and exception.

To refer that this class is untouch for 2 years and during this time no previous sonar analysis failed with this error.

Versions Used

Sonarqube: 7.5
Maven maven plugin: 3.6.0.1398
SonarJava plugin : 5.11 (build 17289)
JDK: 1.8_202
Maven: 3.6.0

Error Observed

[ ERROR ] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.6.0.1398:sonar (default-cli) on project mlff-parent: SonarQube is unable to analyze file : ‘/home/jenkins/slave/workspace/xxx/src/main/java/xxx/xxx/ImageComposer.java’ : index (7) must be less than size (3) -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException : Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.6.0.1398:sonar **

Caused by : java.lang.IndexOutOfBoundsException: index (7) must be less than size (3) at com.google.common.base.Preconditions.checkElementIndex ( Preconditions.java:1329 ) at com.google.common.base.Preconditions.checkElementIndex ( Preconditions.java:1311 ) at com.google.common.collect.ImmutableList$SubList.get ( ImmutableList.java:472 ) at org.sonar.java.checks.PrintfFailCheck.verifyParameters ( PrintfFailCheck.java:207 ) at org.sonar.java.checks.PrintfFailCheck.handlePrintfFormat ( PrintfFailCheck.java:102 ) at org.sonar.java.checks.PrintfFailCheck.checkFormatting ( PrintfFailCheck.java:89 ) at org.sonar.java.checks.PrintfFailCheck.onMethodInvocationFound ( PrintfFailCheck.java:65 ) at org.sonar.java.checks.methods.AbstractMethodDetection.checkInvocation ( AbstractMethodDetection.java:54 ) at org.sonar.java.checks.methods.AbstractMethodDetection.visitNode ( AbstractMethodDetection.java:45 ) at org.sonar.java.model.VisitorsBridge$ScannerRunner.lambda$visit$7 ( VisitorsBridge.java:293 ) at java.util.ArrayList.forEach ( ArrayList.java:1257 )

Steps to Reproduce

I can’t post any code here so is difficult to give you a scenario that helps you to replicate this, but if really need it I can send you the class code (after some pruning) in a private message or mail.

I invoked a top-level Maven target with version 3 and the following goals:

verify $SONAR_MAVEN_GOAL -Dsonar.java.source=1.8 -Dsonar.host.url=$SONAR_HOST_URL -Dsonar.login=$SONAR_AUTH_TOKEN -Dsonar.report.export.path=sonar-report.json

Hello Hugo,

Thanks for the reaching us, and welcome on this forum!

Unfortunately, without any actual source code to reproduce the issue, it’s going to be tough for me to identify the problem in the rule, and eventually fix it. From what I have seen however, the last time the code of the rule changed was for version 5.1 of SonarJava.

Would you mind sending the file causing the issue to me privately? I would need it to identify why the rule is badly checking the parameters of a printf-style method. Please use michael.gumowski[at]sonarsource[dot]com

Regards,
Michael

Hello again Hugo,

Thanks for the information you provided me, it allowed me reproduce and identify the issue. It seems that the rule is extremely badly reacting to strangely formatted String.format() messages. I created the following JIRA ticket to handle it: SONARJAVA-3060.

Note that in order to make your analysis pass, you could chose to temporarily disable rule S2275. I however assigned the ticket fixVersion to the next release of SonarJava (expected in a few days). Because it’s making the analysis crash, we will provide a fix as fast as possible.

Thanks again for helping us identifying the issue.

Michael