Community
Participate
Working Groups
The fix released for bug 201469 has introduced a regression in the generation of 3.3 performance results which leads to the following NPE: java.lang.NullPointerException at java.util.Arrays$ArrayList.<init>(Arrays.java:2342) at java.util.Arrays.asList(Arrays.java:2328) at org.eclipse.test.internal.performance.results.DB_Results.getAllComponents(DB_Results.java:178) at org.eclipse.test.internal.performance.results.PerformanceResults.read(PerformanceResults.java:265) at org.eclipse.test.performance.ui.Main.start(Main.java:709) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:515) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:455) at org.eclipse.equinox.launcher.Main.run(Main.java:1193) at org.eclipse.equinox.launcher.Main.main(Main.java:1169)
The problem happens while cleaning tests with several measures in database per build. I missed the point that some values might be equals to 0 and in this case, the value is not stored in the specific 'values' array => one entry is null and we got this NPE while cleaning these values into one. I'm currently testing a patch to fix this issue...
Created attachment 80952 [details] Proposed patch This patch fixes the problem by initializing values with -1 instead of 0...
Released for 3.4M3. I generated results without any troubles for M20071010-0800 and N20071015-0010 builds. I also tested files generated with this change: 1) N20071015-0010: they are *all* the same than those generated with version v20071023. 2) M20071010-0800: visual comparison with old version is OK
Released new org.eclipse.test.performance jar to basebuilder for upcoming 3.4 builds.
Would it be also taken into account for 3.3 builds or should I also release the fix in R3_3_maintenance branch?
Yes, please release to the R3_3_maintenance branch branch. We have separate builders for each stream of builds. I'll update basebuilder with the new jar once it is available. Thanks!
Reduce the severity as the fix for bug 201469 was not released in R3_3_maintenance branch => generation will not fail for 3.3 builds...
Patch released in R3_3_maintenance stream
basebuilder tagged with new performance plugins for next 3.3.1 stream M build
(In reply to comment #9) > basebuilder tagged with new performance plugins for next 3.3.1 stream M build > Kim, do not forget to change the arguments as well: 1) the 'scenario.pattern' arguments need a '%' at the end to match all scenarios: -scenario.pattern org.eclipse.%.test%" 2) the order of config names is now used to determine the order of the fingerprint displayed in PHP pages: -config eclipseperflnx3_R3.3,eclipseperfwin2_R3.3,eclipseperflnx2_R3.3, eclipseperfwin1_R3.3,eclipseperflnx1_R3.3 3) the 'dataDir' argument must be added to use the incremental version and reduce the generation time to the minimum: -dataDir ${postingDirectory}/data/v33 WARNING: the directory *must* be located at a different place than the one used for the 3.4 builds results generation! Thanks
thanks, I've released those fixes to the 3.3stream builder.
