Community
Participate
Working Groups
Gerrit Jenkins jobs (all projects) report comparator warnings which are not reported by official build. Example: https://ci.eclipse.org/platform/job/eclipse.platform.ui-Gerrit/18021/warnings39Result/source.6626726096164242840/#14795 [WARNING] MavenProject: eclipse.platform.ui:org.eclipse.core.commands:3.9.400-SNAPSHOT @ /home/cbi/genie.platform/workspace/eclipse.platform.ui-Gerrit@2/bundles/org.eclipse.core.commands/.polyglot.build.properties: baseline and build artifacts have same version but different contents no-classifier: different org/eclipse/core/commands/Command.class: different org/eclipse/core/commands/ParameterizedCommand.class: different org/eclipse/core/commands/common/NamedHandleObjectComparator.class: different org/eclipse/core/commands/operations/DefaultOperationHistory.class: different org/eclipse/core/commands/operations/TriggeredOperations.class: different org/eclipse/core/internal/commands/util/Util.class: different [INFO] MavenProject: eclipse.platform.ui:org.eclipse.core.commands:3.9.400-SNAPSHOT @ /home/cbi/genie.platform/workspace/eclipse.platform.ui-Gerrit@2/bundles/org.eclipse.core.commands/.polyglot.build.properties The main artifact has been replaced with the baseline version.
Some findings from the ongoing investigation done by Sravan and me. - A job updates parent pom on Gerrit Jenkins from master every hour ==> same ECJ is used for Gerrit ==> same Tycho is used for Gerrit (and hence same comparator) - Baseline is correct - JRE used to compile is the same - !!! JRE used by Tycho/comparator is NOT the same. Build uses JRE from /shared and Gerrit Jenkins uses the default one from Jenkins. This can be changed according to Sravan: There is a way to add JDK: https://ci.eclipse.org/platform/configureTools/ - The above difference is most likely the problem: javap -verbose differs when using the JRE from build vs. the one from Jenkins NOTE: it does not differ if -verbose is not used Sravan will try to use the JRE from /shared in Gerrit's Jenkins jobs.
I went though the code code for Tycho's comparator, Here are my observations. 1. Tycho tries to disassemble baseline and built classes using asm 7 with SKIP_DEBUG and SKIP_FRAMES flags 2. Do special processing for PACK200 Normalized classes 3. Compare the output if there is a problem in disassembly binary comparison us used. I am using javap for disassembly till now. javap -c generates different disassembled code for baseline and built class files. This happens with same jre. I think JRE is not an issue here. Regarding the JRE for official build and Gerrit build we are using the same JRE for both. In official build the following jre is used JAVA_HOME="/shared/common/jdk1.8.0_x64-latest" In Gerrit build we are using the same. /shared/common/jdk1.8.0_x64-latest My suspicion is on the pack200. There is a special processing for pack200 normalized classes in the comparator. In gerrit comparison the baseline class is pack200 normalized and built class is not
Created attachment 278497 [details] built class disassembled
Created attachment 278498 [details] baseline class disassembled
The attached ones are from gerrit job. there is definitely some change. Need some help in understanding the changes listed here @Jay can you help here?
(In reply to Sravan Kumar Lakkimsetti from comment #3) > Created attachment 278497 [details] > built class disassembled (In reply to Sravan Kumar Lakkimsetti from comment #4) > Created attachment 278498 [details] > baseline class disassembled I created a small test program using asm to disassemble class files. The above files are out of that
Could it be that we had those warnings for a long time and just no one observed/reported them?
(In reply to Dani Megert from comment #7) > Could it be that we had those warnings for a long time and just no one > observed/reported them? It could be a possibility Dani
After some more analysis I found this With pomless builds, maven creates .polyglot.build.properties file for build purposes. This is causing the comparator to fail in our gerrit builds. To test my theory I am going to revert pomless change for org.eclipse.core.commands now and will verify gerrit build tomorrow. Reverting would update the qualifier. So the comparator won't even attempt for comparison till there is a new baseline.
New Gerrit change created: https://git.eclipse.org/r/141653
Gerrit change https://git.eclipse.org/r/141653 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=34a4bc6cde838145488624f3c81e01e24cef9d95
(In reply to Eclipse Genie from comment #11) > Gerrit change https://git.eclipse.org/r/141653 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=34a4bc6cde838145488624f3c81e01e24cef9d95 Last night's build did not create a new bundle for baseline. So I am triggering a new build shortly
New Gerrit change created: https://git.eclipse.org/r/141692
Gerrit change https://git.eclipse.org/r/141692 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=437bb818c8fb79382a9c2e5ddf7884be500f9b0c
Looks like the differing code corresponds to the inlined icuBigDecimal.getConstructor() => Class.getConstructor(), which has changed between 1.8 and 12. As Dani said, what might be causing this is the JDK used by Tycho, which also means a different system libraries are used for compilation.
If it's a baseline issue caused by pomless build, then adding the .polyglot.build.properties to the various excludes in parent pom should help.
New Gerrit change created: https://git.eclipse.org/r/141694
(In reply to Mickael Istria from comment #16) > If it's a baseline issue caused by pomless build, then adding the > .polyglot.build.properties to the various excludes in parent pom should help. The differences are not from having that file but from class file differences
(In reply to Jay Arthanareeswaran from comment #15) > Looks like the differing code corresponds to the inlined > icuBigDecimal.getConstructor() => Class.getConstructor(), which has changed > between 1.8 and 12. > > As Dani said, what might be causing this is the JDK used by Tycho, which > also means a different system libraries are used for compilation. Unfortunately I am unable to back this up with a reproducible small test. Will continue to look at this from the compiler perspective.
Even after adding pom.xml I am seeing comparator errors. Need to take a fresh look on this issue. 476 [WARNING] MavenProject: org.eclipse.core:org.eclipse.core.commands:3.9.400-SNAPSHOT @ /home/sravanl/git/eclipse.platform.releng.aggregator/eclipse.platform.ui/bundles/org.eclipse.core.commands/pom.xml: baseline and build artifacts ha ve same version but different contents 477 no-classifier: different 478 org/eclipse/core/commands/Command.class: different 479 org/eclipse/core/commands/ParameterizedCommand.class: different 480 org/eclipse/core/commands/common/NamedHandleObjectComparator.class: different 481 org/eclipse/core/commands/operations/DefaultOperationHistory.class: different 482 org/eclipse/core/commands/operations/TriggeredOperations.class: different 483 org/eclipse/core/internal/commands/util/Util.class: different 484 485 [INFO] MavenProject: org.eclipse.core:org.eclipse.core.commands:3.9.400-SNAPSHOT @ /home/sravanl/git/eclipse.platform.releng.aggregator/eclipse.platform.ui/bundles/org.eclipse.core.commands/pom.xml 486 The main artifact has been replaced with the baseline version. 487 The following attached artifacts have been replaced with the baseline version: [sources]
(In reply to Jay Arthanareeswaran from comment #15) > Looks like the differing code corresponds to the inlined > icuBigDecimal.getConstructor() => Class.getConstructor(), which has changed > between 1.8 and 12. This isn't true. The differing code is about the three empty blocks. And for the same empty block we seem to be generating different byte code now comparing with the baseline. IMO, this is a clear case of something different either in the source code or the compiler. I just don't know what it is yet.
(In reply to Jay Arthanareeswaran from comment #21) > (In reply to Jay Arthanareeswaran from comment #15) > > Looks like the differing code corresponds to the inlined > > icuBigDecimal.getConstructor() => Class.getConstructor(), which has changed > > between 1.8 and 12. > > This isn't true. The differing code is about the three empty blocks. And for > the same empty block we seem to be generating different byte code now > comparing with the baseline. > > IMO, this is a clear case of something different either in the source code > or the compiler. I just don't know what it is yet. Sravan, is Gerrit using the same ECJ version than the official build?
It is the same ecj compiler that is used in both official build and Gerrit build compiler gets downloaded here in case of gerrit https://ci.eclipse.org/platform/view/Gerrit/job/eclipse.platform.ui-Gerrit/ws/.repository/org/eclipse/jdt/ecj/3.18.0.v20190430-1056/ incase of daily build eco gets downloaded here https://build.eclipse.org/eclipse/builds/4I/localMavenRepo/org/eclipse/jdt/ecj/3.18.0.v20190430-1056/ They both gets downloaded from https://repo.eclipse.org/content/repositories/eclipse-staging/org/eclipse/jdt/ecj/ The compiler selection is based on the cbi-ecj-version in parent pom. For gerrit the parent pom is pulled in(latest will get pulled) from https://repo.eclipse.org/content/repositories/eclipse-snapshots/org/eclipse/eclipse-platform-parent/4.12.0-SNAPSHOT/ and in case of regular build we have parent pom in our source. https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse-platform-parent/pom.xml These two are synced up using https://ci.eclipse.org/releng/job/deploy-eclipse-platform-parent-pom-4.12/ this job runs hourly
For confirmation you can see the version information here compile log for Gerrit: https://ci.eclipse.org/platform/job/eclipse.platform.ui-Gerrit/ws/bundles/org.eclipse.core.commands/target/compilelogs/@dot.xml compile log for daily build: http://download.eclipse.org/eclipse/downloads/drops4/I20190507-1800/compilelogs/plugins/org.eclipse.core.commands_3.9.400.v20190507-0554/@dot.xml both have version="v20190430-1056, 3.18.0"
> This isn't true. The differing code is about the three empty blocks. And for > the same empty block we seem to be generating different byte code now > comparing with the baseline. I meant to say, empty catch blocks. It still beats me why we would do that. I still can't reproduce this even trying several compiler code generation options :(
I am trying doing one more test. Trying out Tycho version 1.3.0
New Gerrit change created: https://git.eclipse.org/r/141850
Gerrit change https://git.eclipse.org/r/141850 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=bd9acf9462a16cafb64751991c251576485bce47
New Gerrit change created: https://git.eclipse.org/r/141851
Gerrit change https://git.eclipse.org/r/141851 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=72f78801a230ee296e73d55daeacfbed30177af6
(In reply to Sravan Kumar Lakkimsetti from comment #26) > I am trying doing one more test. > > Trying out Tycho version 1.3.0 Getting the same issue by downgrading also
I am wondering about the usage of the -inlineJSR compiler option. Do we know if this is same in the official build too?
(In reply to Jay Arthanareeswaran from comment #32) > I am wondering about the usage of the -inlineJSR compiler option. Do we know > if this is same in the official build too? here is the compile log containing commandline options. https://download.eclipse.org/eclipse/downloads/drops4/I20190508-1800/compilelogs/plugins/org.eclipse.core.commands_3.9.400.v20190507-0554/@dot.xml -inlineJSR is used in official build as well
(In reply to Jay Arthanareeswaran from comment #32) > I am wondering about the usage of the -inlineJSR compiler option. Do we know > if this is same in the official build too? This is also red herring. I am seeing this code in TryStatement#generateCode() that appear to be generating the two versions of the code we are discussing: if ((catchVar = this.catchArguments[i].binding).resolvedPosition != -1) { codeStream.store(catchVar, false); catchVar.recordInitializationStartPC(codeStream.position); codeStream.addVisibleLocalVariable(catchVar); } else { codeStream.pop(); } Continuing...
Phew, this is our old friend option preserve Local variable. Looks like this is on in build and off in gerrits!
(In reply to Jay Arthanareeswaran from comment #35) > Phew, this is our old friend option preserve Local variable. Looks like this > is on in build and off in gerrits! Where is it set? How can it be different?
(In reply to Dani Megert from comment #36) > (In reply to Jay Arthanareeswaran from comment #35) > > Phew, this is our old friend option preserve Local variable. Looks like this > > is on in build and off in gerrits! > > Where is it set? How can it be different? it is set in root pom.xml of platform.ui, introduced by bug 506778 This change causes gerrit and regular build to have different compiler options.
(In reply to Sravan Kumar Lakkimsetti from comment #37) > (In reply to Dani Megert from comment #36) > > (In reply to Jay Arthanareeswaran from comment #35) > > > Phew, this is our old friend option preserve Local variable. Looks like this > > > is on in build and off in gerrits! > > > > Where is it set? How can it be different? > > it is set in root pom.xml of platform.ui, introduced by bug 506778 > > This change causes gerrit and regular build to have different compiler > options. That at first did not help because the option is on (preserve) in the default workspace and in the projects. Now, reading the Javadoc for that options reveals it: /** * Compiler option ID: Preserving Unused Local Variables. * <p>Unless requested to preserve unused local variables (that is, never read), the * compiler will optimize them out, potentially altering debugging.</p> * <dl> * <dt>Option id:</dt><dd><code>"org.eclipse.jdt.core.compiler.codegen.unusedLocal"</code></dd> * <dt>Possible values:</dt><dd><code>{ "preserve", "optimize out" }</code></dd> * <dt>Default:</dt><dd><code>"preserve"</code></dd> * </dl> * @category CompilerOptionID */ ==> Since the option is not specified when using ECJ, the option is set to off (optimize out). This is what we see in our official build. However for the IDE/JavaCorePreferenceInitializer the option is on (preserve) and that's also what's in the project settings file. I will try to verify that with the upcoming Gerrit change.
New Gerrit change created: https://git.eclipse.org/r/141947
(In reply to Eclipse Genie from comment #39) > New Gerrit change created: https://git.eclipse.org/r/141947 That did not work, but reverting the change for bug 506778 fixes the issue (see bug 540419).
(In reply to Dani Megert from comment #40) > (In reply to Eclipse Genie from comment #39) > > New Gerrit change created: https://git.eclipse.org/r/141947 > That did not work Reason: -properties overrides most of the arguments and wins.
Fixed by reverting the changes from bug 506778. Thanks everyone for your effort on this bug. We (or at least I) learned a lot!
