You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by Nicolas Peru <ni...@sonarsource.com> on 2016/10/11 09:34:27 UTC
Wrong bytecode generated for getters and setters of volatile field
Hi,
I am the developer of the SonarQube Java Analyzer.
While we are doing an analysis we are reading bytecode of external
dependencies of the compilation unit analyzed.
A user recently came back on SonarQube google group complaining about a
failure on one of the invariant we have in our bytecode analysis where a
bridge method was not marked as synthetic.
Investigating a bit further it appears that the failing method is a getter
generated by groovy compiler and that it is indeed (wrongly) marked as
bridge because it is the same bit as the one used for volatile for fields.
This is an issue that is supposed to be solved a long time ago per :
https://issues.apache.org/jira/browse/GROOVY-3726
A reproducer of this issue can be found by compiling the following project
: https://github.com/Petikoch/sonarqube_issue and looking at the generated
.class files.
Related discussion about this specific problem on SonarQube Google groups:
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/sonarqube/htmOuRPm4-c/AVMlDxvOCgAJ
as I am no Groovy expert, can anyone shed a light on this ? It sounds to me
like there is still a bug on Groovy side on this but I might be wrong.
Thanks for your help.
--
*Nicolas PERU | SonarSource*
*Senior Developer*
http://sonarsource.com
https://twitter.com/benzonico
Re: Wrong bytecode generated for getters and setters of volatile field
Posted by Nicolas Peru <ni...@sonarsource.com>.
Thanks Paul.
Glad I could help figure this out.
Good luck with the bug then.
Cheers,
Le mar. 11 oct. 2016 à 13:54, Paul King <pa...@asert.com.au> a écrit :
> This is a bug in Groovy. Normally for a property those modifier bits
> are cleared:
>
> https://github.com/apache/groovy/blob/master/src/main/org/codehaus/groovy/classgen/Verifier.java#L641-L647
>
> But for @Bindable it creates its own setters and bypass the above logic:
>
> https://github.com/apache/groovy/blob/master/src/main/groovy/beans/BindableASTTransformation.java#L247-L258
>
> The same will be true for @Vetoable:
>
> https://github.com/apache/groovy/blob/master/src/main/groovy/beans/VetoableASTTransformation.java#L311-L323
>
> I created the following issue to track the problem:
> https://issues.apache.org/jira/browse/GROOVY-7969
>
> Cheers, Paul.
>
> On Tue, Oct 11, 2016 at 7:34 PM, Nicolas Peru
> <ni...@sonarsource.com> wrote:
> > Hi,
> >
> > I am the developer of the SonarQube Java Analyzer.
> > While we are doing an analysis we are reading bytecode of external
> > dependencies of the compilation unit analyzed.
> >
> > A user recently came back on SonarQube google group complaining about a
> > failure on one of the invariant we have in our bytecode analysis where a
> > bridge method was not marked as synthetic.
> >
> > Investigating a bit further it appears that the failing method is a
> getter
> > generated by groovy compiler and that it is indeed (wrongly) marked as
> > bridge because it is the same bit as the one used for volatile for
> fields.
> >
> > This is an issue that is supposed to be solved a long time ago per :
> > https://issues.apache.org/jira/browse/GROOVY-3726
> >
> > A reproducer of this issue can be found by compiling the following
> project :
> > https://github.com/Petikoch/sonarqube_issue and looking at the generated
> > .class files.
> >
> > Related discussion about this specific problem on SonarQube Google
> groups:
> >
> https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/sonarqube/htmOuRPm4-c/AVMlDxvOCgAJ
> >
> > as I am no Groovy expert, can anyone shed a light on this ? It sounds to
> me
> > like there is still a bug on Groovy side on this but I might be wrong.
> >
> > Thanks for your help.
> >
> >
> > --
> > Nicolas PERU | SonarSource
> > Senior Developer
> > http://sonarsource.com
> > https://twitter.com/benzonico
>
--
*Nicolas PERU | SonarSource*
*Senior Developer*
http://sonarsource.com
https://twitter.com/benzonico
Re: Wrong bytecode generated for getters and setters of volatile field
Posted by Paul King <pa...@asert.com.au>.
This is a bug in Groovy. Normally for a property those modifier bits
are cleared:
https://github.com/apache/groovy/blob/master/src/main/org/codehaus/groovy/classgen/Verifier.java#L641-L647
But for @Bindable it creates its own setters and bypass the above logic:
https://github.com/apache/groovy/blob/master/src/main/groovy/beans/BindableASTTransformation.java#L247-L258
The same will be true for @Vetoable:
https://github.com/apache/groovy/blob/master/src/main/groovy/beans/VetoableASTTransformation.java#L311-L323
I created the following issue to track the problem:
https://issues.apache.org/jira/browse/GROOVY-7969
Cheers, Paul.
On Tue, Oct 11, 2016 at 7:34 PM, Nicolas Peru
<ni...@sonarsource.com> wrote:
> Hi,
>
> I am the developer of the SonarQube Java Analyzer.
> While we are doing an analysis we are reading bytecode of external
> dependencies of the compilation unit analyzed.
>
> A user recently came back on SonarQube google group complaining about a
> failure on one of the invariant we have in our bytecode analysis where a
> bridge method was not marked as synthetic.
>
> Investigating a bit further it appears that the failing method is a getter
> generated by groovy compiler and that it is indeed (wrongly) marked as
> bridge because it is the same bit as the one used for volatile for fields.
>
> This is an issue that is supposed to be solved a long time ago per :
> https://issues.apache.org/jira/browse/GROOVY-3726
>
> A reproducer of this issue can be found by compiling the following project :
> https://github.com/Petikoch/sonarqube_issue and looking at the generated
> .class files.
>
> Related discussion about this specific problem on SonarQube Google groups:
> https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/sonarqube/htmOuRPm4-c/AVMlDxvOCgAJ
>
> as I am no Groovy expert, can anyone shed a light on this ? It sounds to me
> like there is still a bug on Groovy side on this but I might be wrong.
>
> Thanks for your help.
>
>
> --
> Nicolas PERU | SonarSource
> Senior Developer
> http://sonarsource.com
> https://twitter.com/benzonico