-----Original Message-----
From: Daniel Fuchs [mailto:daniel.fu...@oracle.com]
Sent: Dienstag, 22. November 2016 13:42
To: Volker Simonis <volker.simo...@gmail.com>; Langer, Christoph
<christoph.lan...@sap.com>; Langer, Christoph <christoph.lan...@sap.com>
Cc: Chris Hegarty <chris.hega...@oracle.com>; code-tools-
d...@openjdk.java.net; core-libs-dev@openjdk.java.net; jtreg-
u...@openjdk.java.net
Subject: Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission"
"accessDeclaredMembers")
Hi guys,
Are you running the tests with the exploded jdk or with the image?
I'm seeing failures with the exploded jdk.
That could explain the difference with permission checks.
best regards,
-- daniel
On 22/11/16 12:32, Daniel Fuchs wrote:
Hi Volker,
On 22/11/16 12:25, Chris Hegarty wrote:
Volker,
Just to add, jtreg has support in its tags to start the test VM with a
security manager and a specified policy. In the case of the test failure
you are seeing, the built-in jtreg support is not being used. Instead,
the test is executing with a test-specific system property that is being
used to trigger the programatic setting of a security manager with a
generated policy. I think this explains why you are not seeing any
policy file in the JTwork directory.
What is odd is that the stack trace you are seeing appears to be
before the test’s main entry point, so I would not expect to the
security manager to be active at this point ( since no test code
has run ). My previous comment regarding 7901792 is not relevant
since it relates to tests executing with a security manager set
through jtreg tags.
I agree with Chris - I believe CODETOOLS-7901792 was a red herring.
I'm going to try the jtreg you pointed at and see if there's any
difference (I'm using jtreg 4.2 fcs b03).
Is there anything in the environment that could trigger the VM
to start up with a security manager enabled?
This is a good question.
best regards,
-- daniel
-Chris.
On 22 Nov 2016, at 12:13, Volker Simonis <volker.simo...@gmail.com>
wrote:
Hi Daniel,
thanks for your support - this problem really drives us crazy!
What version of jtreg are you using?
If you are using a central one which was configured and build by
Oracle, could you please also try with the one from
https://adopt-
openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/
?
Where can we find the generated policy files? It seems they get
deleted during test post-run cleanup phase (at least I could not find
any of them under JTwork). Is there a way to get a more detailed trace
on how JTreg executes testng and to leave all the generated files in
place after the test?
I'm currently running the following JAXP test and get the same error
as described by Christoph:
/tmp/jtreg/bin/jtreg -verbose:summary -jdk
/output-jdk9-hs-dbg/images/jdk/
/OpenJDK/jdk9-
hs/jaxp/test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.jav
a
What I don't really understand is how this is supposed to work at all,
because every JAXP test which runs with "-DrunSecMngr=true" will
execute the following code from JAXPPolicyManager:
/*
* Install a SecurityManager along with a default Policy to allow
testNG to
* run when there is a security manager.
*/
private JAXPPolicyManager() {
// Backing up policy and security manager for restore
policyBackup = Policy.getPolicy();
smBackup = System.getSecurityManager();
// Set customized policy
setDefaultPermissions();
Policy.setPolicy(policy);
System.setSecurityManager(new SecurityManager());
}
Won't this code override the settings from the policy file which was
potentially installed by jtreg for testng?
The setDefaultPermissions() sets some special permissions for testng,
but not "accessDeclaredMembers":
private void setDefaultPermissions() {
//Permissions to set security manager and policy
addPermission(new SecurityPermission("getPolicy"));
addPermission(new SecurityPermission("setPolicy"));
addPermission(new RuntimePermission("setSecurityManager"));
//Properties that jtreg and TestNG require
addPermission(new
PropertyPermission("testng.show.stack.frames", "read"));
addPermission(new PropertyPermission("test.src", "read"));
addPermission(new PropertyPermission("test.classes", "read"));
addPermission(new
PropertyPermission("dataproviderthreadcount", "read"));
addPermission(new PropertyPermission("experimental", "read"));
}
If I add the line:
addPermission(new RuntimePermission("accessDeclaredMembers"));
to setDefaultPermissions(), the test will succeed.
I saw that an early version of "JDK-8067170: Enable security manager
on JAXP unit tests" contained that extra permission, but you objected
(http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-
July/042520.html)
and it was removed in the final version.
Any more hints?
Thanks,
Volker
On Tue, Nov 22, 2016 at 12:24 PM, Daniel Fuchs
<daniel.fu...@oracle.com> wrote:
Hi Christoph,
Is there anything funny with the place jtreg is installed?
like:
- path contains whitespaces
- path is accessible through links or mount points...
It seems clear that the issue here is that testng classes are
missing some permissions, so I was wondering whether that could
be caused by the actual path to testng.jar not matching the
path injected in the policy file.
I'm using jtreg 4.2 fcs b03, and have no issues with the jaxp tests:
$ cd jaxp/tests
$ rm -r JT*
$ jtreg -verbose:summary -ignore:quiet -jdk
../../build/macosx-x86_64-normal-server-release/images/jdk javax/
=> the only test that fails is
javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh, but that's
expected
(it's in the ProblemList.txt).
The other thing to take care of, is not to run two jtreg process
concurrently if they point to the same JT* directories. If you do
that then you might experience weird failures with permissions
issues (it seems to mess the policy files).
best regards,
-- daniel
On 22/11/16 10:52, Langer, Christoph wrote:
Yes, please find it here:
http://cr.openjdk.java.net/~clanger/jtreg/XSLTFunctionsTest.jtr
-----Original Message-----
From: Chris Hegarty [mailto:chris.hega...@oracle.com]
Sent: Dienstag, 22. November 2016 11:03
To: Langer, Christoph <christoph.lan...@sap.com>
Cc: core-libs-dev@openjdk.java.net; code-tools-...@openjdk.java.net;
jtreg-
u...@openjdk.java.net
Subject: Re: Issues running JAXP jtreg tests
("java.lang.RuntimePermission"
"accessDeclaredMembers")
On 22 Nov 2016, at 09:43, Langer, Christoph
<christoph.lan...@sap.com>
wrote:
Hi Chris,
thanks for this hint. However, we've already seen this change and
rebuilt
jtreg with the latest jtreg repo. But it doesn't change a thing.
Also, the download from https://adopt-
openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/
where I
would
suppose latest jtreg sources were used, don't help.
Am I missing something?
Is it possible to post, or upload to cr.o.j.n, the jtr of the failing
test?
-Chris.
Best regards
Christoph
-----Original Message-----
From: Chris Hegarty [mailto:chris.hega...@oracle.com]
Sent: Dienstag, 22. November 2016 10:08
To: Langer, Christoph <christoph.lan...@sap.com>
Cc: core-libs-dev@openjdk.java.net;
code-tools-...@openjdk.java.net;
jtreg-
u...@openjdk.java.net
Subject: Re: Issues running JAXP jtreg tests
("java.lang.RuntimePermission"
"accessDeclaredMembers")
Hi Christoph,
Can you please ensure that your build of jtreg contains the fix for
7901792
[1].
7901792 grants <JTREG_HOME>/lib/testng.jar all permissions.
-Chris.
[1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901792
On 22 Nov 2016, at 08:38, Langer, Christoph
<christoph.lan...@sap.com>
wrote:
Hi,
I'm currently struggling while running jtreg tests for the jaxp
depot.
There are several tests that fail with the same symptom. I
always get
exceptions like:
java.security.AccessControlException: access denied
("java.lang.RuntimePermission" "accessDeclaredMembers")
at
java.base/java.security.AccessControlContext.checkPermission(AccessControlCo
ntext.java:471)
at
java.base/java.security.AccessController.checkPermission(AccessController.java
:894)
at
java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:5
48)
at
java.base/java.lang.Class.checkMemberAccess(Class.java:2595)
at
java.base/java.lang.Class.getDeclaredMethods(Class.java:2162)
at
org.testng.internal.ClassHelper.extractMethods(ClassHelper.java:217)
at
org.testng.internal.ClassHelper.getAvailableMethods(ClassHelper.java:182)
at
org.testng.internal.Parameters.findDataProvider(Parameters.java:323)
at
org.testng.internal.Parameters.findDataProvider(Parameters.java:259)
at
org.testng.internal.Parameters.handleParameters(Parameters.java:419)
at
org.testng.internal.Invoker.handleParameters(Invoker.java:1274)
at
org.testng.internal.Invoker.createParameters(Invoker.java:989)
at
org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1079)
at
org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.
java:129)
at
org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112)
at org.testng.TestRunner.privateRun(TestRunner.java:782)
at org.testng.TestRunner.run(TestRunner.java:632)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:366)
at
org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319)
at org.testng.SuiteRunner.run(SuiteRunner.java:268)
at
org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at
org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1169)
at org.testng.TestNG.run(TestNG.java:1064)
at
com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:
224)
at
com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:
188)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod
AccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin
gMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:537)
at
com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j
ava:110)
at java.base/java.lang.Thread.run(Thread.java:844)
For instance the test
javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java fails like
this.
It's calling "testng -DrunSecMngr=true" and obviously some
important
permission for testing is missing with that.
I'm using most current jtreg (with testng-6.9.10.jar)
Thanks for any help.
Best regards
Christoph
