[
https://issues.apache.org/jira/browse/DERBY-6697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-6697:
--------------------------------------
Attachment: d6697-1a.diff
The failure in MissingPermissionsTest is easily fixed by adding the required
permissions to its custom policy file, and adjusting BaseTestCase.execJavaCmd()
so that it propagates the jacoco.enabled property that enables the extra
permissions if JaCoCo is used.
For DBOAccessTest I think we would ideally want to change the permissions so
that they are only granted to the JaCoCo jar file and not to all code bases. I
am not sure if this is possible. My guess is that it was originally done this
way because JaCoCo didn't wrap privileged operations in doPrivileged() calls.
Even so, there is a small change that can be made to DBOAccessTest so that it
passes both with and without JaCoCo. Where this test expects procedure calls to
fail with an AccessControlException, it is not essential for the test that they
fail exactly that way. Those procedure calls are given dummy arguments, where
the point is to check that they don't fail with an authorization error if
authorization is not enabled. Because of the dummy arguments, the calls are
expected to fail further down the road after they have passed the authorization
check.
For some of the procedure calls, the expected error further down the road is an
AccessControlException because a dummy file name argument points to a directory
that derby.jar is not allowed to read from (the current working directory). And
the extra permissions granted to all code bases when running with JaCoCo,
includes read permission on that directory, so the AccessControlException is
not raised when running with JaCoCo.
By changing those dummy file name arguments to point to a directory that
derby.jar is allowed to read even without the extra permissions granted for
JaCoCo, we change the expected error from an AccessControlException to file not
found or something similar. This way, when we enable the broader permissions
required by JaCoCo, it doesn't change anything for the test, since it is
already permitted to read those files.
The attached patch [^d6697-1a.diff] makes the suggested changes. This makes the
failing test cases pass in my environment, both with and without JaCoCo.
> Failures when running tests with JaCoCo
> ---------------------------------------
>
> Key: DERBY-6697
> URL: https://issues.apache.org/jira/browse/DERBY-6697
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.12.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Attachments: d6697-1a.diff
>
>
> Some test cases have been failing in the code coverage tests at
> https://builds.apache.org/job/Derby-JaCoCo/ since Jul 28. The failing tests
> are:
> org.apache.derbyTesting.functionTests.tests.lang.DBOAccessTest.test_6616
> org.apache.derbyTesting.functionTests.tests.lang.DBOAccessTest$NoAuthorization.test_6616
> org.apache.derbyTesting.unitTests.junit.MissingPermissionsTest.testMissingFilePermission
> The first two fail with the following message: SQLJ.INSTALL_JAR should have
> succeeded: 46001 Exception while accessing jar file using URL 'foo'.
> The last one fails with this stack trace:
> {noformat}
> subprocess run failed: :Spawned MPT exitCode=134
> STDERR:
> java.security.AccessControlException: access denied ("java.io.FilePermission"
> "/x1/jenkins/jenkins-slave/workspace/Derby-JaCoCo/trunk/junit_20140806_1917"
> "read")
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
> at
> java.security.AccessController.checkPermission(AccessController.java:559)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at java.io.File.exists(File.java:770)
> at java.io.File.mkdirs(File.java:1263)
> at
> org.jacoco.agent.rt.internal_9dd1198.output.FileOutput.startup(FileOutput.java:46)
> at org.jacoco.agent.rt.internal_9dd1198.Agent.startup(Agent.java:126)
> at org.jacoco.agent.rt.internal_9dd1198.Agent.getInstance(Agent.java:56)
> at org.jacoco.agent.rt.internal_9dd1198.PreMain.premain(PreMain.java:45)
> 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:606)
> at
> sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:382)
> at
> sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:397)
> Exception in thread "main" java.lang.reflect.InvocationTargetException
> 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:606)
> at
> sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:382)
> at
> sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:397)
> Caused by: java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "shutdownHooks")
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
> at
> java.security.AccessController.checkPermission(AccessController.java:559)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.Runtime.addShutdownHook(Runtime.java:209)
> at org.jacoco.agent.rt.internal_9dd1198.Agent.getInstance(Agent.java:57)
> at org.jacoco.agent.rt.internal_9dd1198.PreMain.premain(PreMain.java:45)
> ... 6 more
> STDOUT:
> FATAL ERROR in native method: processing of -javaagent failed
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
