With sc/qa/unoapi enabled in subsequentcheck, it failed for me at least once at LOG> Log started 28.10.2011 - 17:26:53 checking: [sc.ScCellRangeObj::com::sun::star::chart::XChartData] is iface: [com.sun.star.chart.XChartData] testcode: [ifc.chart._XChartData] LOG> Execute: addChartDataChangeEventListener() com.sun.star.uno.RuntimeException: LOG> at com.sun.star.lib.uno.environments.remote.Job.remoteUnoRequestRaisedException(Job.java:177) LOG> at com.sun.star.lib.uno.environments.remote.Job.execute(Job.java:143) LOG> at com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:338) LOG> at com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:307) LOG> at com.sun.star.lib.uno.environments.remote.JavaThreadPool.enter(JavaThreadPool.java:91) LOG> at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge.sendRequest(java_remote_bridge.java:640) LOG> at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.request(ProxyFactory.java:150) LOG> at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.invoke(ProxyFactory.java:132) LOG> at $Proxy79.setData(Unknown Source) LOG> at ifc.chart._XChartData._addChartDataChangeEventListener(_XChartData.java:76) LOG> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) LOG> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) LOG> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) LOG> at java.lang.reflect.Method.invoke(Method.java:616) LOG> at lib.MultiMethodTest.invokeTestMethod(MultiMethodTest.java:406) LOG> at lib.MultiMethodTest.callMethod(MultiMethodTest.java:384) LOG> at lib.MultiMethodTest.executeMethod(MultiMethodTest.java:372) LOG> at lib.MultiMethodTest.run(MultiMethodTest.java:236) LOG> at base.java_fat.executeInterfaceTest(java_fat.java:573) LOG> at base.java_fat.executeTest(java_fat.java:237) LOG> at org.openoffice.Runner.run(Runner.java:240) LOG> at org.openoffice.test.UnoApiTest.test(UnoApiTest.java:45) LOG> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) LOG> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) LOG> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) LOG> at java.lang.reflect.Method.invoke(Method.java:616) LOG> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) LOG> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) LOG> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) LOG> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) LOG> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) LOG> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) LOG> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79) LOG> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71) LOG> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49) LOG> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) LOG> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) LOG> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) LOG> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) LOG> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) LOG> at org.junit.runners.ParentRunner.run(ParentRunner.java:236) LOG> at org.junit.runners.Suite.runChild(Suite.java:128) LOG> at org.junit.runners.Suite.runChild(Suite.java:24) LOG> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) LOG> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) LOG> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) LOG> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) LOG> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) LOG> at org.junit.runners.ParentRunner.run(ParentRunner.java:236) LOG> at org.junit.runner.JUnitCore.run(JUnitCore.java:157) LOG> at org.junit.runner.JUnitCore.run(JUnitCore.java:136) LOG> at org.junit.runner.JUnitCore.run(JUnitCore.java:117) LOG> at org.junit.runner.JUnitCore.runMain(JUnitCore.java:98) LOG> at org.junit.runner.JUnitCore.runMainAndExit(JUnitCore.java:53) LOG> at org.junit.runner.JUnitCore.main(JUnitCore.java:45) LOG> addChartDataChangeEventListener(): .FAILED LOG> Execute: removeChartDataChangeEventListener() LOG> starting required method: addChartDataChangeEventListener() LOG> ! Required method addChartDataChangeEventListener() failed LOG> removeChartDataChangeEventListener(): .FAILED LOG> Execute: getNotANumber() LOG> Current NotANumber is 2.2250738585072014E-308 Method getNotANumber() finished with state OK LOG> getNotANumber(): PASSED.OK LOG> Execute: isNotANumber() LOG> starting required method: getNotANumber() Method isNotANumber() finished with state OK LOG> isNotANumber(): PASSED.OK LOG> disposing xSheetDoc ***** State for sc.ScCellRangeObj::com::sun::star::chart::XChartData ****** [sc.ScCellRangeObj::com::sun::star::chart::XChartData::addChartDataChangeEventListener()] is testcode: [addChartDataChangeEventListener()] - .FAILED [sc.ScCellRangeObj::com::sun::star::chart::XChartData::removeChartDataChangeEventListener()] is testcode: [removeChartDataChangeEventListener()] - .FAILED Whole interface: PASSED.FAILED
Disabled failing tests as <http://cgit.freedesktop.org/libreoffice/core/commit/?id=eb76f71658696cb974f607b7238a8544386f715c>. Please revert when fixed.
Commit https://git.libreoffice.org/core/+/eb7a731bcfbacec15b77889f0ac545d36ef5ad19%5E%21 has fixed the issue.
It's not clear to me how the commit from comment 2 fixes whatever was the underlying issue of comment 0, but I would at least expect that a fix would revert the commit from comment 1?
(In reply to Stephan Bergmann from comment #3) > It's not clear to me how the commit from comment 2 fixes whatever was the > underlying issue of comment 0, but I would at least expect that a fix would > revert the commit from comment 1? Okay, the wording isn't the best. I ran the Junit test again and it didn't crash on my machine: LOG> Log started 23.03.2019 - 17:20:17 checking: [sc.ScCellRangeObj::com::sun::star::chart::XChartData] is iface: [com.sun.star.chart.XChartData] testcode: [ifc.chart._XChartData] LOG> Execute: addChartDataChangeEventListener() Method addChartDataChangeEventListener() finished with state OK LOG> addChartDataChangeEventListener(): COMPLETED.OK LOG> Execute: removeChartDataChangeEventListener() LOG> starting required method: addChartDataChangeEventListener() Method removeChartDataChangeEventListener() finished with state OK LOG> removeChartDataChangeEventListener(): COMPLETED.OK LOG> Execute: getNotANumber() LOG> Current NotANumber is 2.2250738585072014E-308 Method getNotANumber() finished with state OK LOG> getNotANumber(): COMPLETED.OK LOG> Execute: isNotANumber() LOG> starting required method: getNotANumber() Method isNotANumber() finished with state OK LOG> isNotANumber(): COMPLETED.OK LOG> disposing xSheetDoc warn:svl.items:3247:3264:svl/source/items/itempool.cxx:398: old secondary pool: EditEngineItemPool of pool: XOutdevItemPool must be empty. ***** State for sc.ScCellRangeObj::com::sun::star::chart::XChartData ****** Whole interface: COMPLETED.OK So the problem must be fixed sometime ago. The reason I didn't make changes to commit in comment 1 is: I talked with moggi a couple of times if I should make changes to the file sc/qa/unoapi/knownissues.xcl and he always advised me against it.
(In reply to Jens Carl from comment #4) > I ran the Junit test again and it didn't crash on my machine: [...] > So the problem must be fixed sometime ago. No, it only means that it didn't happen to fail for that one test run. (Comment 0 "it failed for me at least once" is a rather strong indication that it didn't fail reliably, only sporadically, but I should have worded that more clearly.) > The reason I didn't make changes to commit in comment 1 is: I talked with > moggi a couple of times if I should make changes to the file > sc/qa/unoapi/knownissues.xcl and he always advised me against it. If a qadevOOo-based Java test is removed (replaced by a C++ test, as is done in the commit from comment 2 IIUC), I see no reason to keep any dead knownissues.xcl entries around. On the contrary, such dead entries only cause confusion IMO.
(In reply to Stephan Bergmann from comment #5) > No, it only means that it didn't happen to fail for that one test run. > (Comment 0 "it failed for me at least once" is a rather strong indication > that it didn't fail reliably, only sporadically, but I should have worded > that more clearly.) Agreed. Now things are more clear to me. > > The reason I didn't make changes to commit in comment 1 is: I talked with > > moggi a couple of times if I should make changes to the file > > sc/qa/unoapi/knownissues.xcl and he always advised me against it. > > If a qadevOOo-based Java test is removed (replaced by a C++ test, as is done > in the commit from comment 2 IIUC), I see no reason to keep any dead > knownissues.xcl entries around. On the contrary, such dead entries only > cause confusion IMO. I agree and if wanted I can clean the file. I still would keep the bug as resolved and if the error pops up again we should create a new bug report.
(In reply to Jens Carl from comment #6) > (In reply to Stephan Bergmann from comment #5) > > > The reason I didn't make changes to commit in comment 1 is: I talked with > > > moggi a couple of times if I should make changes to the file > > > sc/qa/unoapi/knownissues.xcl and he always advised me against it. > > > > If a qadevOOo-based Java test is removed (replaced by a C++ test, as is done > > in the commit from comment 2 IIUC), I see no reason to keep any dead > > knownissues.xcl entries around. On the contrary, such dead entries only > > cause confusion IMO. > > I agree and if wanted I can clean the file. yes, please > I still would keep the bug as resolved and if the error pops up again we > should create a new bug report. fine with me
Jens Carl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/8dabb2ae2d34f94a50ef5f94bf4bf01b2aca2071%5E%21 Related tdf#43309 Enable test It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.