On Fri, Feb 12, 2021 at 6:36 PM James McCoy <james...@jamessan.com> wrote: > > One of the new JavaHL tests > (testCrash_RequestChannel_nativeRead_AfterException) is failing on > Debian's armhf, mips64el, mipsel, and powerpc builders: > > https://buildd.debian.org/status/logs.php?pkg=subversion&ver=1.14.1-1&suite=sid > > There was 1 failure: > 1) > testCrash_RequestChannel_nativeRead_AfterException(org.apache.subversion.javahl.BasicTests)junit.framework.AssertionFailedError: > IOException was caught in run() > at > org.apache.subversion.javahl.BasicTests$TestTunnelAgent.joinAndTest(BasicTests.java:4477) > at > org.apache.subversion.javahl.BasicTests.testCrash_RequestChannel_nativeRead_AfterException(BasicTests.java:4679) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at org.apache.subversion.javahl.RunTests.main(RunTests.java:119) > > FAILURES!!! > Tests run: 147, Failures: 1, Errors: 0 > > On most of those, we're also getting these warnings: > > OpenJDK 64-Bit Zero VM warning: You have loaded library > subversion-1.14.1/BUILD/subversion/bindings/javahl/native/.libs/libsvnjavahl-1.so.0.0.0 > which might have disabled stack guard. The VM will try to fix the stack > guard now. > It's highly recommended that you fix the library with 'execstack -c > <libfile>', or link it with '-z noexecstack'. > .........................WARNING in native method: JNI call made without > checking exceptions when required to from CallVoidMethodV > at java.lang.Object.getClass(java.base@11.0.10/Native Method) > at > java.util.ArrayList.equals(java.base@11.0.10/ArrayList.java:560) > at > org.apache.subversion.javahl.BasicTests.testBasicChangelist(BasicTests.java:2626) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.10/Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.10/NativeMethodAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.10/DelegatingMethodAccessorImpl.java:43) > at > java.lang.reflect.Method.invoke(java.base@11.0.10/Method.java:566) > at junit.framework.TestCase.runTest(TestCase.java:177) > at junit.framework.TestCase.runBare(TestCase.java:142) > at junit.framework.TestResult$1.protect(TestResult.java:122) > at junit.framework.TestResult.runProtected(TestResult.java:142) > at junit.framework.TestResult.run(TestResult.java:125) > at junit.framework.TestCase.run(TestCase.java:130) > at junit.framework.TestSuite.runTest(TestSuite.java:241) > at junit.framework.TestSuite.run(TestSuite.java:236) > at junit.framework.TestSuite.runTest(TestSuite.java:241) > at junit.framework.TestSuite.run(TestSuite.java:236) > at junit.textui.TestRunner.doRun(TestRunner.java:116) > at junit.textui.TestRunner.doRun(TestRunner.java:109) > at junit.textui.TestRunner.run(TestRunner.java:77) > at org.apache.subversion.javahl.RunTests.main(RunTests.java:119) > > If I re-run the tests without clearing out > <builddir>/subversion/bindings/javahl/test-work, then the test passes. > Hopefully that helps provide some insight. > > I can run tests as needed on Debian's porterboxes.
[ cc += Alexandr Miloslavkiy, as he wrote those new tests ] Thanks for reporting these, James. Which JDK version is this? Or is it different on the different architectures? Did you also test 1.14.0 previously with the same JDK, and you didn't see those warnings then? -- Johan
