Hi, we are running jtreg with something like -jdk:<build directory>/images/jdk. So would that be the exploded version or not?
FWIW: I think all test that fail don't have void test methods but the test methods expect input parameters and hence a tag @Test(dataProvider = "...") exists. Can it be that we are using a testng framework that is "too new" and maybe contains something which makes it not work in the jaxp scenario? Best, Christoph > -----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 > >>>>>>> > >>>>>>> > >>>>> > >>>> > >> > >
