On Thu, Oct 15, 2020 at 12:14 PM <amiloslavs...@apache.org> wrote:
>
> Author: amiloslavskiy
> Date: Thu Oct 15 10:14:30 2020
> New Revision: 1882520
>
> URL: http://svn.apache.org/viewvc?rev=1882520&view=rev
> Log:
> JavaHL: Fix 'JNI call made with exception pending' error
>
> It is incorrect to call Java method with 'CallObjectMethod' when there
> is an unhandled Java exception already pending. The fix is to
> temporarily move exception out of the way.
>
> This error is easily seen when running JavaHL tests.

Hi Alexandr,

I agree with this change, but was wondering what you meant by "This
error is easily seen when running JavaHL tests"? Is there a warning or
...? Can you explain how to see the effect of "the absence of this
fix"?

Same remark / question for your next commit, r1882521, where you say
in the commit message:
    "These warnings are seen in JavaHL tests due to '-Xcheck:jni' option."

For context: I'm building on Windows, with AdoptOpenJDK-11.0.6.10. I
have performed a "release" build, but have adjusted win-tests.py to
pass the -Xcheck:jni option. I'm not seeing any warnings that point to
this, when running the javahl testsuite.

I am however seeing a bunch of other warnings, but I assume these are
totally unrelated to the work you did on the javahl-1.14-fixes branch:

I do get 8 warnings with this sort of message (always similar
stacktrace, always coming from UtilTests.testFileMerge, line 120):
[[[
WARNING: JNI local refs: 33, exceeds capacity: 32
        at java.net.NetworkInterface.getAll(java.base@11.0.6/Native Method)
        at 
java.net.NetworkInterface.getNetworkInterfaces(java.base@11.0.6/NetworkInterface.java:359)
        at 
sun.security.provider.SeedGenerator.addNetworkAdapterInfo(java.base@11.0.6/SeedGenerator.java:229)
        at 
sun.security.provider.SeedGenerator$1.run(java.base@11.0.6/SeedGenerator.java:179)
        at 
sun.security.provider.SeedGenerator$1.run(java.base@11.0.6/SeedGenerator.java:167)
        at java.security.AccessController.doPrivileged(java.base@11.0.6/Native
Method)
        at 
sun.security.provider.SeedGenerator.getSystemEntropy(java.base@11.0.6/SeedGenerator.java:167)
        at 
sun.security.provider.AbstractDrbg$SeederHolder.<clinit>(java.base@11.0.6/AbstractDrbg.java:551)
        at 
sun.security.provider.AbstractDrbg.getEntropyInput(java.base@11.0.6/AbstractDrbg.java:505)
        at 
sun.security.provider.AbstractDrbg.getEntropyInput(java.base@11.0.6/AbstractDrbg.java:494)
        at 
sun.security.provider.AbstractDrbg.instantiateIfNecessary(java.base@11.0.6/AbstractDrbg.java:696)
        - locked <0x000000008a727f88> (a sun.security.provider.HashDrbg)
        at 
sun.security.provider.AbstractDrbg.engineNextBytes(java.base@11.0.6/AbstractDrbg.java:378)
        at 
sun.security.provider.AbstractDrbg.engineNextBytes(java.base@11.0.6/AbstractDrbg.java:334)
        at 
sun.security.provider.DRBG.engineNextBytes(java.base@11.0.6/DRBG.java:233)
        at 
java.security.SecureRandom.nextBytes(java.base@11.0.6/SecureRandom.java:741)
        at 
java.security.SecureRandom.next(java.base@11.0.6/SecureRandom.java:798)
        at java.util.Random.nextLong(java.base@11.0.6/Random.java:424)
        at 
java.io.File$TempDirectory.generateFile(java.base@11.0.6/File.java:1930)
        at java.io.File.createTempFile(java.base@11.0.6/File.java:2078)
        at 
org.apache.subversion.javahl.UtilTests.testFileMerge(UtilTests.java:120)
        at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.6/Native
Method)
        at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.6/NativeMethodAccessorImpl.java:62)
        at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.6/DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(java.base@11.0.6/Method.java:566)
        at junit.framework.TestCase.runTest(TestCase.java:176)
        at junit.framework.TestCase.runBare(TestCase.java:141)
        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:129)
        at junit.framework.TestSuite.runTest(TestSuite.java:252)
        at junit.framework.TestSuite.run(TestSuite.java:247)
        at junit.framework.TestSuite.runTest(TestSuite.java:252)
        at junit.framework.TestSuite.run(TestSuite.java:247)
        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)
]]]

I suppose I have some lower default limit for these JNI local refs ...
perhaps this should be adjusted somewhere in our test suite (maybe
this was already done for unix, but not for Windows, but I haven't
investigated further)

Thanks,
-- 
Johan

Reply via email to