Community
Participate
Working Groups
Running all of the GProf tests locally, I get 10 failures. Most of them are similar to the stack trace below. I'm going to add these tests to the ones we run with our builds and hopefully they won't fail on build.eclipse.org. If so, we can close this bug. Otherwise, let's try to figure out what's causing the failures. The failing tests are: foocpp_gprof_input:CSV-CALLGRAPH foocpp_gprof_input:CSV-CALLGRAPH-TIMED foocpp_gprof_input:CSV-FILE foocpp_gprof_input:CSV-FILE-TIMED foocpp_gprof_input:CSV-FUNCTION foocpp_gprof_input:CSV-FUNCTION-TIMED bigtest_gprof_input:Aggregate foocpp_gprof_input:Aggregate partially-pg-build_gprof_input:Aggregate foox_gprof_input:Aggregate -- Error Log from JUnit -- Class: org.eclipse.linuxtools.gprof.test.GprofTest.1 Method: foocpp_gprof_input:CSV-CALLGRAPH Actual: null Expected: null Stack Trace: junit.framework.AssertionFailedError: Comparing ref file (/home/overholt/workspaces/linuxtools2/org.eclipse.linuxtools.gprof.test/./foocpp_gprof_input/testCallgraphView.ref)and dump file (/home/overholt/workspaces/linuxtools2/org.eclipse.linuxtools.gprof.test/./foocpp_gprof_input/testCallgraphView.dump): not correspond expected:<true> but was:<false> at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:280) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:146) at org.eclipse.linuxtools.gprof.test.STJunitUtils.compareIgnoreEOL(STJunitUtils.java:119) at org.eclipse.linuxtools.gprof.test.STJunitUtils.testCSVExport(STJunitUtils.java:52) at org.eclipse.linuxtools.gprof.test.GprofTest.testView(GprofTest.java:169) at org.eclipse.linuxtools.gprof.test.GprofTest$1.runTest(GprofTest.java:88) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) at org.eclipse.pde.internal.junit.runtime.UITestApplication$1.run(UITestApplication.java:114) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3468) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3115) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2405) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113) at org.eclipse.pde.internal.junit.runtime.UITestApplication.start(UITestApplication.java:46) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) at org.eclipse.equinox.launcher.Main.run(Main.java:1311) at org.eclipse.equinox.launcher.Main.main(Main.java:1287)
Postponing until 0.4 release.
Xavier, I'd like to add the GProf plugins to our nightly builds. Are you able to track down these failures?
I'm going to add the tests to the automated build so fixing this will become more time-sensitive :) Building locally may help reproduce the problem if you can't do it from within Eclipse. Other project committers have gone through local build test failure diagnosing and may be able to help. This wiki page may also be of help: http://wiki.eclipse.org/Linux_Tools_Project/Releng#Building_locally
Hi Andrew, I committed (rev #23411) some changes in JUnit plugin test (org.eclipse.linuxtools.gprof.test). Can you please try again to run gprof tests ? And if you obtain any failure, can you provide me the stack trace, and (if any) the generated file (*.dump) ? Many thanks,
The tests are now run as part of each build. The reason the build was broken by your change the other day was because your test plugin is actually a fragment (unlike our other plugins). It seems to work, though. You can see the failures here: https://build.eclipse.org/hudson/job/cbi-linuxtools-Galileo/482/testReport/ Feel free to open individual bugs for the test failures. We can't release 0.4 until there are zero failures. Thanks, Xavier.
Hi Andrew, Ok, I work on it. Do you know the version of binutils (especially addr2line) used during hudson builds ?
(In reply to comment #6) > Do you know the version of binutils (especially addr2line) used during hudson > builds ? $ addr2line --version GNU addr2line 2.16.91.0.5 20051219 (SUSE Linux) Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. $ rpm -q binutils binutils-2.16.91.0.5-23.31 In general it's best if you _don't_ depend on the output of the build system's underlying tools and instead spoof its output for various circumstances and deal with un-expected output gracefully. Just my €0.02 :)
The problem is that gprof plugin depends on underlaying tools, such as addr2line :) addr2line is used to transform addresses into function names and source location (this solution is at least twice faster than using eclipse Elf parser, and allows lazy computing) These 2 remaining failures are caused by a wrong addr2line output. Its seems that some address are not decoded properly for C++ programs. I've tried with several version of addr2line (2.14.90.0.4, 2.15.92.0.2, 2.17, 2.19.1) and never had this problem. I think these failures have raised an interesting problem: It seems that relying on addr2line output may cause trouble... I can re-write the test to do not rely on addr2line output, but it will not fix the problem :(
Are there bugs filed about the slowness of the CDT Elf parser? Perhaps it's better to just move to using it in the meantime? Or add version check guards around the addr2line calls?
I've tested locally with addr2line 2.16.91.0.5. I confirm that addr2line-2.16.91.0.5 output differs from all other version of addr2line (2.14.90.0.4, 2.15.92.0.2, 2.17, 2.19.1 are OK).
Gotta love those differences :) Thanks for fixing the test failures, Xavier!
