Re: SonarQube analysis error with "bridge method not marked as synthetic"

[Nicolas Peru]

Hi Andrey, 

This is an issue happening when reading bytecode of class Tuple2. 

I am trying to reproduce the problem, but for this I need to analyze closely the .class file but the version you point out for scala-library can't be found in maven central repository and other version do not seem to have this trouble : can you create somehow a small reproducer with a small piece of code using some classes of this scala library and provide us the precise version you are using ? That will help to investigate and fix the issue.

Thanks in advance !

Cheers, 

Le mar. 2 août 2016 à 17:07, Andrey Hsiao <andre...@gmail.com> a écrit :

Hello

We have a maven module (Java project) and when analyzing with sonar maven plugin (3.0.2), below exception will be thrown.

Caused by: java.lang.IllegalStateException: bridge method not marked as synthetic in class scala/Tuple2
        at com.google.common.base.Preconditions.checkState(Preconditions.java:174)
        at org.sonar.java.resolve.BytecodeVisitor.visitMethod(BytecodeVisitor.java:209)
        at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:911)
        at org.objectweb.asm.ClassReader.accept(ClassReader.java:693)
        at org.objectweb.asm.ClassReader.accept(ClassReader.java:506)
        at org.sonar.java.resolve.BytecodeCompleter.complete(BytecodeCompleter.java:100)
        at org.sonar.java.resolve.JavaSymbol.complete(JavaSymbol.java:111)

The offending class is from one scala library dependency in pom:

<dependency>
  <groupId>scala-library</groupId>
  <artifactId>scala-library</artifactId>
  <version>1.0</version>
</dependency>

After testing, it seems very other module with this dependency will fail the same.

I am not sure whether it's sonar scala analysis issue (it's a Java project), or what will be the workaround.

Our platform is: CentOS 7/Sonar 5.6 docker

Thanks in advance

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/2ef27b36-d435-41f1-8879-6c6e79c4e422%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Nicolas PERU | SonarSource

Senior Developer
http://sonarsource.com

https://twitter.com/benzonico

[Peti Koch]

Any updates on this?

I'm facing a similar issue ("bridge method not marked as synthetic")in the analysis of a mixed Java/Groovy codebase... (Java 8 Update 60, Groovy 2.4.7, SonarQube 6.0, Windows 7)

Best regards,
Peti

[nicolas...@sonarsource.com]

Hi Peti,

To get any help you should at least provide your analysis logs with detailed error/stacktrace , and also indicate which version of the Java Plugin you're using.

And side-question: is your Java project using AspectJ weaving ?

Best regards,

Nicolas

[Peti Koch]

Hello Nicolas,

I created this little reproducer project:

https://github.com/Petikoch/sonarqube_issue

Does this help?

Best regards,

Peti

[Peti Koch]

Ah... and sorry. No, the project doesn't use AspectJ. 

It uses some typical Groovy AST-Transformations.

Best regards,

Peti

Am Montag, 5. September 2016 14:23:53 UTC+2 schrieb nicolas...@sonarsource.com:

[Peti Koch]

Nicolas, any findings yet? Does https://github.com/Petikoch/sonarqube_issue help?

Best regards,
Peti

Am Montag, 5. September 2016 14:23:53 UTC+2 schrieb nicolas...@sonarsource.com:

[Nicolas Peru]

Hi, 

Thanks for the reproducer. The problem comes from the fact that you use volatile fields and groovy generates getters and setters for those but does not clear the bit for the volatile flag for those (as it should if I believe this (fairly old) groovy ticket : https://issues.apache.org/jira/browse/GROOVY-3726 ) thus it has the same bit set, but for methods this means it is a bridge method (which it is not) and we have a check state that bridge method should be synthetic methods.

All in all : This sounds like a bug on groovy side but I may be wrong as I am no groovy expert and it seems quite a big one to be this IMO.

I pinged one of the groovy dev on twitter, and I'll probably ask a question around this on the groovy mailing list soon.

Cheers, 

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/c273a6f5-032e-4173-b904-5ccb15a7b085%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Peti Koch]

Hi Nicolas,

thank you for the analysis.

Is it a good behaviour for SonarQube to "defensively crash" because of such a 3rd party issue?
Wouldn't it be better to just report/show such problems as "not analyzable source-files"?

Just some thoughts...

Have a nice week!

Best regards,
Peti

[Peti Koch]

Nicolas,

I just checked the sourcecode for Groovy's @Bindable annotation: groovy.beans.BindableASTTransformation. I guess the problem is rather there...
BindableASTTransformation generates additional methods and fields with their modifier bits. I guess it doesn't handle the volatile property case.
I found the open issue https://issues.apache.org/jira/browse/GROOVY-4959 regarding "thread-safe @Bindable"...

Best regards,
Peti

Am Donnerstag, 22. September 2016 16:33:46 UTC+2 schrieb Nicolas Peru:

[Nicolas Peru]

FYI : I just posted a question on groovy user mailing list that led to creation of an issue on their side see : http://groovy.329449.n5.nabble.com/Wrong-bytecode-generated-for-getters-and-setters-of-volatile-field-tp5736036p5736046.html

and corresponding ticket : https://issues.apache.org/jira/browse/GROOVY-7969

For me this is an issue on groovy side and nothing really we could/should do on SQ analyzer side.

Cheers, 

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/49bc3546-166d-4df8-bdfe-451c71e6b3ec%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Peti Koch]

Hi Nicolas,

thanks a lot for the update!

Best regards,
Peti

[paul.ki...@gmail.com]

Fix applied, so will be in the next Groovy release(s) - not scheduled yet but should be in the next couple of weeks if all goes well.

Cheers, Paul.

[hmo...@gmail.com]

Hi all,

I'm facing the same issue with a project that uses MapDB as 3rd party library.

MapDB is built with Kotlin, and Kotlin compiler emits code with bridge methods that are not flagged with ACC_SYNTHETIC.

I've started a discussion in Kotlin forum, in which you guys might want to chime in.

The JVM Spec does not apparently explicitly require synthetic flag for bridge methods, but all bridge methods are generated and therefore synthetic.

I think it leaves an ambiguity... it seems we all agree that "bridge implies synthetic", but:

- Kotlin compiler seems to interpret this as "ACC_BRIDGE" flag is enough because it implies "synthetic".
- SonarQube analyzer seems to interpret this as "any method flagged ACC_BRIDGE must also be flagged ACC_SYNTHETIC".

Two questions for Sonar guys:

- which is right ?

- whomever is right, is it a good behaviour for SonarQube to "defensively crash" because of such a 3rd party issue? (*)

(*) echoing Peti's earlier comment: Wouldn't it be better to just report/show such problems as "not analyzable source-files"?

Cheers,

Hugues

[Nicolas Peru]

Hi, 

This is a nice question. 

I tend to think that SonarJava analyzer is a bit too strict here : because, even though this is how javac behaves this is actually not _required_ by the spec  : https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.6 

A method may be marked with the ACC_SYNTHETIC flag to indicate that it was generated by a compiler and does not appear in source code, unless it is one of the methods named in §4.7.8.

Keyword here is _may_

Not that interestingly this word disappeared from jvms 8 which makes it more ambiguous (but not explicitely mandatory) :

https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.6

Given all this : I tend to think that Kotlin should mark its bridge method as Synthetic but SonarJava is a bit too strict on this : 

 https://jira.sonarsource.com/browse/SONARJAVA-2044

(even though it helps to reveal this kind of problems in compilers :) ) 

Thanks for reporting it. 

Cheers, 

--

You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/b9cdaf55-87f6-487d-8f68-fac714e56a0a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[hmo...@gmail.com]

Thanks Nicolas,

I suspect you'll see this kind of stuff more and more as Kotlin (and other alternative JVM languages) rise, so better be safe on the SQ Java analyzer side.

Merci again,

Hugues

[hmo...@gmail.com]

SonarJava plugin 4.5 was released yesterday, I upgraded and it fixed my problem, thanks!