You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by James McCoy <ja...@jamessan.com> on 2021/02/12 17:36:13 UTC
JavaHL test failure and warning in 1.14.1
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.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: JavaHL test failure and warning in 1.14.1
Posted by James McCoy <ja...@jamessan.com>.
On Mon, Feb 15, 2021 at 08:25:26AM +0100, Johan Corveleyn wrote:
> On Fri, Feb 12, 2021 at 6:36 PM James McCoy <ja...@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?
This is OpenJDK 11.0.10.
> Did you also test 1.14.0 previously with the same JDK, and you didn't
> see those warnings then?
The initial 1.14.0 upload was built with OpenJDK 11.0.7 and it also
showed the warnings. I just didn't notice at the time, since it
successfully built. :)
The warning is from a separate, existing test, so I should have
separated that from the actual test failure.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: JavaHL test failure and warning in 1.14.1
Posted by Alexandr Miloslavskiy <al...@syntevo.com>.
For two days, I struggled to build SVN on my Ubuntu 20.04 with external
serf. Finally I managed [1], tomorrow I'll try to reproduce the problem
in tests.
[1] <a8...@syntevo.com>
Re: JavaHL test failure and warning in 1.14.1
Posted by James McCoy <ja...@jamessan.com>.
On Wed, Nov 24, 2021 at 03:10:21PM +0300, Alexandr Miloslavskiy wrote:
> On 24.11.2021 15:07, James McCoy wrote:
> > The comment says IOException, but this is InterruptedException. Is that
> > intentional?
>
>
> Catching InterruptedException is simply to be able to call
> 'tunnelAgent.join()'. The comment is correct. The difference between
> 'tunnelAgent.join()' and 'tunnelAgent.joinAndTest()' is testing for
> IOException.
Thanks! This patch has worked for me, as well.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: JavaHL test failure and warning in 1.14.1
Posted by Alexandr Miloslavskiy <al...@syntevo.com>.
On 24.11.2021 15:07, James McCoy wrote:
> The comment says IOException, but this is InterruptedException. Is that
> intentional?
Catching InterruptedException is simply to be able to call
'tunnelAgent.join()'. The comment is correct. The difference between
'tunnelAgent.join()' and 'tunnelAgent.joinAndTest()' is testing for
IOException.
Re: JavaHL test failure and warning in 1.14.1
Posted by James McCoy <ja...@jamessan.com>.
On Wed, Nov 24, 2021 at 02:13:20AM +0300, Alexandr Miloslavskiy wrote:
> Indeed there was a race condition where TunnelAgent could begin writing at
> the same time when pipe is being closed. This resulted in an unexpected
> IOException, which was detected by the test.
> Please find the patch attached.
> Index: subversion/bindings/javahl/tests/org/apache/subversion/javahl/BasicTests.java
> ===================================================================
> --- subversion/bindings/javahl/tests/org/apache/subversion/javahl/BasicTests.java (revision 1895276)
> +++ subversion/bindings/javahl/tests/org/apache/subversion/javahl/BasicTests.java (working copy)
> @@ -4676,7 +4676,19 @@
> // RuntimeException("Test exception") is expected here
> }
>
> - tunnelAgent.joinAndTest();
> + // In this test, there is a race condition that sometimes results in
> + // IOException when 'WAIT_TUNNEL' tries to read from a pipe that
> + // already has its read end closed. This is not an error, but
> + // it's hard to distinguish this case from other IOException which
> + // indicate a problem. To reproduce, simply wrap this test's body in
> + // a loop. The workaround is to ignore any detected IOException.
> + //
> + // tunnelAgent.joinAndTest();
> + try {
> + tunnelAgent.join();
> + } catch (InterruptedException e) {
The comment says IOException, but this is InterruptedException. Is that
intentional?
> + e.printStackTrace ();
> + }
> }
>
> /**
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: JavaHL test failure and warning in 1.14.1
Posted by Alexandr Miloslavskiy <al...@syntevo.com>.
Indeed there was a race condition where TunnelAgent could begin writing
at the same time when pipe is being closed. This resulted in an
unexpected IOException, which was detected by the test.
This is purely a test issue and should not be a problem for real
applications.
Unfortunately it's hard to identify this in the test, so I decided to
weaken the test to get rid of failures.
To reproduce the failure reliably, wrap body of
'testCrash_RequestChannel_nativeRead_AfterException' in an infinite loop.
Please find the patch attached.
Re: JavaHL test failure and warning in 1.14.1
Posted by Alexandr Miloslavskiy <al...@syntevo.com>.
Thanks!
I tinkered with it a bit to be able to run multiple loops in parallel
(it requires changing '-Dtest.rootdir' to unique absolute dir in each
parallel run).
When running 8 loops at once, with just the guilty test, I can reproduce
the problem within ~10 secs.
Going to investigate tomorrow.
Re: JavaHL test failure and warning in 1.14.1
Posted by James McCoy <ja...@jamessan.com>.
On Tue, Nov 23, 2021 at 12:54:49AM +0300, Alexandr Miloslavskiy wrote:
> On 22.11.2021 3:35, James McCoy wrote:
> > Yes, I just hit it as composing this email, although I hadn't in an
> > earlier 100x loop of the JavaHL suite.
>
> Could you please give more information? :)
I setup as you described in the previous email and ran the whole suite
in a loop.
$ (set -e; for i in $(seq 200); do echo iteration $i; java -Xcheck:jni ...; done)
> Did you reproduce on x86-64?
Yes.
> Were you running the entire suite?
Yes.
> Did you run it from a loop?
Yes.
> Any ideas the would help me to reproduce?
Not off-hand. :( Maybe it's a race condition and increasing load on
your system while the tests are running will help?
Is there anything I can _add_ to my test runs to provide useful debug
information?
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: JavaHL test failure and warning in 1.14.1
Posted by Alexandr Miloslavskiy <al...@syntevo.com>.
On 22.11.2021 3:35, James McCoy wrote:
> Yes, I just hit it as composing this email, although I hadn't in an
> earlier 100x loop of the JavaHL suite.
Could you please give more information? :)
Did you reproduce on x86-64?
Were you running the entire suite?
Did you run it from a loop?
Any ideas the would help me to reproduce?
Re: JavaHL test failure and warning in 1.14.1
Posted by James McCoy <ja...@jamessan.com>.
On Wed, Jul 28, 2021 at 11:55:56PM +0300, Alexandr Miloslavskiy wrote:
> I have tested on Ubuntu 20.04 (on x86-64 arch):
>
> * Ran entire JavaHL test package 130 times
> (using a loop in shell script).
> Not a single error; tests succeed every single time.
>
> * Ran just the reported test 1000 times; again no errors.
> The test is 'org.apache.subversion.javahl.BasicTests.testCrash_RequestChannel_nativeRead_AfterException'
>
> Is the problem reproducible on x86-64 ?
> Is it reproducible by running tests manually ?
Yes, I just hit it as composing this email, although I hadn't in an
earlier 100x loop of the JavaHL suite.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: JavaHL test failure and warning in 1.14.1
Posted by Alexandr Miloslavskiy <al...@syntevo.com>.
I have tested on Ubuntu 20.04 (on x86-64 arch):
* Ran entire JavaHL test package 130 times
(using a loop in shell script).
Not a single error; tests succeed every single time.
* Ran just the reported test 1000 times; again no errors.
The test is
'org.apache.subversion.javahl.BasicTests.testCrash_RequestChannel_nativeRead_AfterException'
Is the problem reproducible on x86-64 ?
Is it reproducible by running tests manually ?
Here's how to run tests:
1) Build SVN
2) cd to the SVN's build directory (where the 'Makefile' file is)
3) run 'make --debug=b check-apache-javahl'
Due to a limitation in 'gen_base.py', it also builds JavaHL.
4) Grab the command executed just before dots are printed
It will begin with something like 'java -Xcheck:jni "-Dtest.rootdir'
5) Run just this command to avoid building each time.
To run just a single test:
In the command you obtained earlier, replace "-Dtest.tests=" with:
"-Dtest.tests=org.apache.subversion.javahl.BasicTests.testCrash_RequestChannel_nativeRead_AfterException"
Re: JavaHL test failure and warning in 1.14.1
Posted by Daniel Sahlberg <da...@gmail.com>.
Den fre 23 juli 2021 14:57Alexandr Miloslavskiy <
alexandr.miloslavskiy@syntevo.com> skrev:
> On 23.07.2021 2:41, Daniel Sahlberg wrote:
> > A kind reminder to check if we ever got to the bottom of this?
>
> Yes, sorry! I consulted my TODO list and found that my boss "kindly"
> moved it to position #9 We agreed that I will fix it next thing, I
> would expect somewhere on Monday next week.
>
Oh, that would be great! I tried to reproduce it but couldn't. Just shout
out if there is anything to test or help out.
Kind regards,
Daniel
>
Re: JavaHL test failure and warning in 1.14.1
Posted by Alexandr Miloslavskiy <al...@syntevo.com>.
On 23.07.2021 2:41, Daniel Sahlberg wrote:
> A kind reminder to check if we ever got to the bottom of this?
Yes, sorry! I consulted my TODO list and found that my boss "kindly"
moved it to position #9 We agreed that I will fix it next thing, I
would expect somewhere on Monday next week.
Re: JavaHL test failure and warning in 1.14.1
Posted by Daniel Sahlberg <da...@gmail.com>.
Den tis 16 feb. 2021 kl 14:10 skrev Alexandr Miloslavskiy <
alexandr.miloslavskiy@syntevo.com>:
> On 16.02.2021 15:27, James McCoy wrote:
>
> > Looks like it's more of a timing issue than something architecture
> > specific. The failure has also occurred on i386 and retries have since
> > succeeded on mipsel, and my manual tests on mips64el have sporadically
> > succeeded.
>
> I can try to have a look tomorrow.
> Alternatively, I wouldn't mind if you just disable the test.
>
A kind reminder to check if we ever got to the bottom of this?
Kind regards,
Daniel Sahlberg
Re: JavaHL test failure and warning in 1.14.1
Posted by Alexandr Miloslavskiy <al...@syntevo.com>.
On 16.02.2021 15:27, James McCoy wrote:
> Looks like it's more of a timing issue than something architecture
> specific. The failure has also occurred on i386 and retries have since
> succeeded on mipsel, and my manual tests on mips64el have sporadically
> succeeded.
I can try to have a look tomorrow.
Alternatively, I wouldn't mind if you just disable the test.
Re: JavaHL test failure and warning in 1.14.1
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Feb 18, 2021 at 10:19 PM Alexandr Miloslavskiy
<al...@syntevo.com> wrote:
>
> Going to take longer, sorry. I'm bombarded with things to take care
> of... While trying to have vacation, huh. Again, of the flaky test
> stands in the way, I wouldn't mind of you just comment it out for now.
Please enjoy your vacation first and foremost, Alexandr :-). I hope
you don't get bombarded too much.
There is nothing on fire here, and as you say: the test can be
commented out or otherwise disabled (as I understand it, the test is
simply exercising the code in a particular way, so if anything errors
out or crashes, it's not really the test's fault).
We should definitely look further into it (and I can try to make some
time for this too, next week or so). But it's nothing that can't wait
for a couple more days / weeks, IMHO.
Cheers,
--
Johan
Re: JavaHL test failure and warning in 1.14.1
Posted by Alexandr Miloslavskiy <al...@syntevo.com>.
Going to take longer, sorry. I'm bombarded with things to take care
of... While trying to have vacation, huh. Again, of the flaky test
stands in the way, I wouldn't mind of you just comment it out for now.
Re: JavaHL test failure and warning in 1.14.1
Posted by James McCoy <ja...@jamessan.com>.
On Mon, Feb 15, 2021 at 08:25:26AM +0100, Johan Corveleyn wrote:
> On Fri, Feb 12, 2021 at 6:36 PM James McCoy <ja...@jamessan.com> wrote:
> >
> > One of the new JavaHL tests
> > (testCrash_RequestChannel_nativeRead_AfterException) is failing on
> > Debian's armhf, mips64el, mipsel, and powerpc builders:
Looks like it's more of a timing issue than something architecture
specific. The failure has also occurred on i386 and retries have since
succeeded on mipsel, and my manual tests on mips64el have sporadically
succeeded.
> > 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
Alexandr, if there's anything that would help triage this, I'll be glad
to test it out on the systems I have access to.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: JavaHL test failure and warning in 1.14.1
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Feb 12, 2021 at 6:36 PM James McCoy <ja...@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