Derby
  1. Derby
  2. DERBY-6079

100's of errors in nightly test run on weme after jacoco property/priviledges checkin

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.10.1.1
    • Fix Version/s: 10.10.1.1
    • Component/s: Test
    • Labels:
      None
    • Environment:
      weme6.2
      Windows XP - x86 - 5.1 build 2600 Service Pack 3
    • Bug behavior facts:
      Regression Test Failure

      Description

      100's of errors in nightly test, all seem to be a null pointer while processing policy files during setup.
      problem is in jvm code, and it seems specific to the weme6.2 jvm.

      The only change being tested in this run was
      For instance:
      330) testAll(org.apache.derbyTesting.functionTests.tests.lang.NativeAuthenticationServiceTest)java.lang.NullPointerException
      at com.ibm.oti.util.DefaultPolicy.addGrant(DefaultPolicy.java:619)
      at com.ibm.oti.util.DefaultPolicy.readPolicy(DefaultPolicy.java:608)
      at com.ibm.oti.util.DefaultPolicy.getSystemPolicy(DefaultPolicy.java:922)
      at com.ibm.oti.util.DefaultPolicy.getPermissionsImpl(DefaultPolicy.java:114)
      at com.ibm.oti.util.DefaultPolicy$1.run(DefaultPolicy.java:67)
      at java.security.AccessController.doPrivileged(AccessController.java:204)
      at com.ibm.oti.util.DefaultPolicy.privateGetPermissions(DefaultPolicy.java:65)
      at com.ibm.oti.util.DefaultPolicy.getPermissions(DefaultPolicy.java:53)
      at java.security.Policy.getPermissions(Policy.java:131)
      at java.security.ProtectionDomain.implies(ProtectionDomain.java:177)
      at java.security.AccessController.checkPermission(AccessController.java:99)
      at java.lang.SecurityManager.checkPermission(SecurityManager.java:534)
      at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:331)
      at java.lang.System.getProperty(System.java:384)
      at java.lang.System.getProperty(System.java:366)
      at org.apache.derbyTesting.junit.BaseTestCase$3.run(BaseTestCase.java:292)
      at java.security.AccessController.doPrivileged(AccessController.java:204)
      at org.apache.derbyTesting.junit.BaseTestCase.getSystemProperty(BaseTestCase.java:288)
      at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDatabase(DropDatabaseSetup.java:86)
      at org.apache.derbyTesting.junit.TestConfiguration$5.tearDown(TestConfiguration.java:868)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:22)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

      Here is link to all errors:
      http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/weme6.2/1447575-suites.All_diff.txt
      http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/weme6.2/1447575-derbyall_diff.txt

      1. derby-6079-1a-propagate_jacocoactive_j9.diff
        0.9 kB
        Kristian Waagan
      2. derby-6079-2a-set_props_j9.diff
        2 kB
        Kristian Waagan

        Issue Links

          Activity

          Mike Matrigali created issue -
          Mike Matrigali made changes -
          Field Original Value New Value
          Bug behavior facts Regression Test Failure [ 10369 ]
          Component/s Test [ 11413 ]
          Component/s Services [ 11415 ]
          Hide
          Mike Matrigali added a comment -

          It looks like the only change that went in before this broke is the following:
          Author: kristwaa
          Date: Mon Feb 18 16:45:48 2013
          New Revision: 1447388

          URL: http://svn.apache.org/r1447388
          Log:
          DERBY-6067: JaCoCo fails with missing permissions when writing results

          Added a "jacoco.active" property, which will grant the required privileges to
          JaCoCo (or more specifically, all code bases) when set to the empty string ("").
          Enabled logic to disable the security manager when spawning processes and at
          the same time obtaining code coverage with JaCoCo.
          Added comment in build.xml, explaining what derby.tests.jacoco.agent is for.

          Show
          Mike Matrigali added a comment - It looks like the only change that went in before this broke is the following: Author: kristwaa Date: Mon Feb 18 16:45:48 2013 New Revision: 1447388 URL: http://svn.apache.org/r1447388 Log: DERBY-6067 : JaCoCo fails with missing permissions when writing results Added a "jacoco.active" property, which will grant the required privileges to JaCoCo (or more specifically, all code bases) when set to the empty string (""). Enabled logic to disable the security manager when spawning processes and at the same time obtaining code coverage with JaCoCo. Added comment in build.xml, explaining what derby.tests.jacoco.agent is for.
          Mike Matrigali made changes -
          Link This issue is related to DERBY-6067 [ DERBY-6067 ]
          Hide
          Kristian Waagan added a comment -

          Sigh, missed this one (the same happened for EMMA with DERBY-5558).

          Attaching patch 1a, which adds the same logic for JaCoCo as for EMMA.

          NOTE: People running weme6.2 must still specify the two properties manually. This is error prone so I'll try to write a patch to remove that manual step. I'll commit the two patches together and and observe what happens with the test run.
          If someone has access to weme6.2 I'd appreciate if you can test the changes

          Show
          Kristian Waagan added a comment - Sigh, missed this one (the same happened for EMMA with DERBY-5558 ). Attaching patch 1a, which adds the same logic for JaCoCo as for EMMA. NOTE: People running weme6.2 must still specify the two properties manually. This is error prone so I'll try to write a patch to remove that manual step. I'll commit the two patches together and and observe what happens with the test run. If someone has access to weme6.2 I'd appreciate if you can test the changes
          Kristian Waagan made changes -
          Hide
          Kristian Waagan added a comment -

          Attaching patch 2a, which is somewhat experimental since I haven't tested it on weme6.2 . The question is if the properties are set soon enough. I'll back this patch out if it doesn't have the intended effect.

          Committed patches 1a and 2a to trunk with revision 1448280.

          Show
          Kristian Waagan added a comment - Attaching patch 2a, which is somewhat experimental since I haven't tested it on weme6.2 . The question is if the properties are set soon enough. I'll back this patch out if it doesn't have the intended effect. Committed patches 1a and 2a to trunk with revision 1448280.
          Kristian Waagan made changes -
          Attachment derby-6079-2a-set_props_j9.diff [ 12570147 ]
          Hide
          Kathey Marsden added a comment - - edited

          So I assume that means weme runs now need both -Djacoco.active="" and -Demma.active="" is that correct?

          We may need to modify http://wiki.apache.org/db-derby/JunitVmIssues accordingly

          Show
          Kathey Marsden added a comment - - edited So I assume that means weme runs now need both -Djacoco.active="" and -Demma.active="" is that correct? We may need to modify http://wiki.apache.org/db-derby/JunitVmIssues accordingly
          Hide
          Myrna van Lunteren added a comment -

          I tried with weme6.2 with trunk sync-ed up to rev 1447387, saw no problem, to 1447388, saw the NullPointerException, and then sync-ed to 1448326 (so after the latest fix), and the NPE went away again, so the fix worked.

          I think we only need the active="" when running derbyall right? Anyway, the junit run with classes seemed to work fine without a jacoco.active setting. Will check on derbyall.

          Show
          Myrna van Lunteren added a comment - I tried with weme6.2 with trunk sync-ed up to rev 1447387, saw no problem, to 1447388, saw the NullPointerException, and then sync-ed to 1448326 (so after the latest fix), and the NPE went away again, so the fix worked. I think we only need the active="" when running derbyall right? Anyway, the junit run with classes seemed to work fine without a jacoco.active setting. Will check on derbyall.
          Hide
          Kristian Waagan added a comment -

          KM> So I assume that means weme runs now need both -Djacoco.active="" and -Demma.active="" is that correct?

          It depends.

          More detailed:
          With patch 1a you need to run with both properties set.
          The intention of patch 2a was to make it possible to run on weme without specifying any of the two properties.
          I believe Myrna has confirmed that patch 2a worked for the JUnit tests.

          My patches on this issue didn't change anything for derbyall, only suites.All (or any other junit test/suite).
          I think Myrna is checking the status for derbyall.

          I can't remember if I added any support for JaCoCo coverage for the tests in derbyall. If there are no more issues, it means that we can remove references to both emma.active and jacoco.active going forward.

          Show
          Kristian Waagan added a comment - KM> So I assume that means weme runs now need both -Djacoco.active="" and -Demma.active="" is that correct? It depends. More detailed: With patch 1a you need to run with both properties set. The intention of patch 2a was to make it possible to run on weme without specifying any of the two properties. I believe Myrna has confirmed that patch 2a worked for the JUnit tests. My patches on this issue didn't change anything for derbyall, only suites.All (or any other junit test/suite). I think Myrna is checking the status for derbyall. I can't remember if I added any support for JaCoCo coverage for the tests in derbyall. If there are no more issues, it means that we can remove references to both emma.active and jacoco.active going forward.
          Hide
          Mike Matrigali added a comment -

          the derbyall run is still failing 98 fail and 3 pass:

          http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/weme6.2/1448491-derbyall_diff.txt

          The most recent nightly suites run looks good after the latest changes. So there is good progress.

          I think the question now is whether we need to change how we run the derbyall tests on weme, or is the intent of the changes that
          nothing should have to change, and more code changes are needed.

          I think all the following changes from the 1st patch may affect derbyall:
          db/derby/code/trunk/build.xml
          db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/RuntimeInfoTest.policy
          db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/SecureServerTest.java
          db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/SysinfoTest.policy
          db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/noAbortPermission.policy
          db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/LDAPTests.policy
          db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/SecurityPolicyReloadingTest.initial.policy
          db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/Derby3980DeadlockTest.policy
          db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/util/derby_tests.policy

          I went on the machine to see if I could post some more info, but it looks like the tests are failing on startup there is
          nothing left after running the tests. could not find derby.log or even out files

          A sample short diff is:

              • Start: recoverBadChecksumLog5 jdkWECE J2ME Foundation Specification v1.1 storeall:storeunit 2013-02-20 22:27:14 ***
                1 del
                < – Unit Test T_RecoverBadLog starting
                2 del
                < – Unit Test T_RecoverBadLog finished
                2 add
                > Exception in thread "main" java.lang.ExceptionInInitializerError
                > Caused by: java.lang.NullPointerException
                > ... 6 more
                Test Failed.
              • End: recoverBadChecksumLog5 jdkWECE J2ME Foundation Specification v1.1 storeall:storeunit 2013-02-20 22:27:16 ***
          Show
          Mike Matrigali added a comment - the derbyall run is still failing 98 fail and 3 pass: http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/weme6.2/1448491-derbyall_diff.txt The most recent nightly suites run looks good after the latest changes. So there is good progress. I think the question now is whether we need to change how we run the derbyall tests on weme, or is the intent of the changes that nothing should have to change, and more code changes are needed. I think all the following changes from the 1st patch may affect derbyall: db/derby/code/trunk/build.xml db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/RuntimeInfoTest.policy db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/SecureServerTest.java db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/SysinfoTest.policy db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/noAbortPermission.policy db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/LDAPTests.policy db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/SecurityPolicyReloadingTest.initial.policy db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/store/Derby3980DeadlockTest.policy db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/util/derby_tests.policy I went on the machine to see if I could post some more info, but it looks like the tests are failing on startup there is nothing left after running the tests. could not find derby.log or even out files A sample short diff is: Start: recoverBadChecksumLog5 jdkWECE J2ME Foundation Specification v1.1 storeall:storeunit 2013-02-20 22:27:14 *** 1 del < – Unit Test T_RecoverBadLog starting 2 del < – Unit Test T_RecoverBadLog finished 2 add > Exception in thread "main" java.lang.ExceptionInInitializerError > Caused by: java.lang.NullPointerException > ... 6 more Test Failed. End: recoverBadChecksumLog5 jdkWECE J2ME Foundation Specification v1.1 storeall:storeunit 2013-02-20 22:27:16 ***
          Hide
          Mike Matrigali added a comment -

          here is an example of one of the stacks, seems similar to those that were failing in junit tests:

          Exception in thread "main" java.lang.NullPointerException
          at com.ibm.oti.util.DefaultPolicy.addGrant(DefaultPolicy.java:619)
          at com.ibm.oti.util.DefaultPolicy.readPolicy(DefaultPolicy.java:608)
          at com.ibm.oti.util.DefaultPolicy.getSystemPolicy(DefaultPolicy.java:922)
          at com.ibm.oti.util.DefaultPolicy.getPermissionsImpl(DefaultPolicy.java:114)
          at com.ibm.oti.util.DefaultPolicy$1.run(DefaultPolicy.java:67)
          at java.security.AccessController.doPrivileged(AccessController.java:204)
          at com.ibm.oti.util.DefaultPolicy.privateGetPermissions(DefaultPolicy.java:65)
          at com.ibm.oti.util.DefaultPolicy.getPermissions(DefaultPolicy.java:53)
          at java.security.Policy.getPermissions(Policy.java:131)
          at java.security.ProtectionDomain.implies(ProtectionDomain.java:177)
          at java.security.AccessController.checkPermission(AccessController.java:99)
          at java.lang.SecurityManager.checkPermission(SecurityManager.java:534)
          at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:331)
          at java.lang.System.getProperty(System.java:384)
          at java.lang.System.getProperty(System.java:366)
          at org.apache.derby.iapi.tools.i18n.LocalizedResource.run(Unknown Source)
          at java.security.AccessController.doPrivileged(AccessController.java:204)
          at org.apache.derby.iapi.tools.i18n.LocalizedResource.getEnvProperty(Unknown Source)
          at org.apache.derby.iapi.tools.i18n.LocalizedResource.init(Unknown Source)
          at org.apache.derby.iapi.tools.i18n.LocalizedResource.init(Unknown Source)
          at org.apache.derby.iapi.tools.i18n.LocalizedResource.<init>(Unknown Source)
          at org.apache.derby.iapi.tools.i18n.LocalizedResource.getInstance(Unknown Source)
          at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source)
          at org.apache.derby.impl.tools.ij.Main.main(Unknown Source)
          at org.apache.derby.tools.ij.main(Unknown Source)

          Show
          Mike Matrigali added a comment - here is an example of one of the stacks, seems similar to those that were failing in junit tests: Exception in thread "main" java.lang.NullPointerException at com.ibm.oti.util.DefaultPolicy.addGrant(DefaultPolicy.java:619) at com.ibm.oti.util.DefaultPolicy.readPolicy(DefaultPolicy.java:608) at com.ibm.oti.util.DefaultPolicy.getSystemPolicy(DefaultPolicy.java:922) at com.ibm.oti.util.DefaultPolicy.getPermissionsImpl(DefaultPolicy.java:114) at com.ibm.oti.util.DefaultPolicy$1.run(DefaultPolicy.java:67) at java.security.AccessController.doPrivileged(AccessController.java:204) at com.ibm.oti.util.DefaultPolicy.privateGetPermissions(DefaultPolicy.java:65) at com.ibm.oti.util.DefaultPolicy.getPermissions(DefaultPolicy.java:53) at java.security.Policy.getPermissions(Policy.java:131) at java.security.ProtectionDomain.implies(ProtectionDomain.java:177) at java.security.AccessController.checkPermission(AccessController.java:99) at java.lang.SecurityManager.checkPermission(SecurityManager.java:534) at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:331) at java.lang.System.getProperty(System.java:384) at java.lang.System.getProperty(System.java:366) at org.apache.derby.iapi.tools.i18n.LocalizedResource.run(Unknown Source) at java.security.AccessController.doPrivileged(AccessController.java:204) at org.apache.derby.iapi.tools.i18n.LocalizedResource.getEnvProperty(Unknown Source) at org.apache.derby.iapi.tools.i18n.LocalizedResource.init(Unknown Source) at org.apache.derby.iapi.tools.i18n.LocalizedResource.init(Unknown Source) at org.apache.derby.iapi.tools.i18n.LocalizedResource.<init>(Unknown Source) at org.apache.derby.iapi.tools.i18n.LocalizedResource.getInstance(Unknown Source) at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source) at org.apache.derby.impl.tools.ij.Main.main(Unknown Source) at org.apache.derby.tools.ij.main(Unknown Source)
          Hide
          Myrna van Lunteren added a comment -

          I experimented, and it seems that indeed, because there is now and added property in functionTests/util/derby_tests.policy, we need to add that to the settings for running derbyall with weme6.2.
          I'll take care of adding that in our runs, and updating the JVM specific wiki documentation.
          This is not needed for running junit tests (with weme or otherwise. Unless - or so I assume - you want to run jacoco).

          Show
          Myrna van Lunteren added a comment - I experimented, and it seems that indeed, because there is now and added property in functionTests/util/derby_tests.policy, we need to add that to the settings for running derbyall with weme6.2. I'll take care of adding that in our runs, and updating the JVM specific wiki documentation. This is not needed for running junit tests (with weme or otherwise. Unless - or so I assume - you want to run jacoco).
          Hide
          Kristian Waagan added a comment -

          ML> I experimented, and it seems that indeed, because there is now and added property in functionTests/util/derby_tests.policy, we need to add that to the settings for running derbyall with weme6.2.

          Yes, looks like it. I think there's also a privilege missing for JaCoCo when running with derbyall, but that isn't as pressing since you have to opt in to run with JaCoCo.
          If the derbyall tests works for weme6.2 when specifying the two properties manually, I'm content with that.

          ML> This is not needed for running junit tests (with weme or otherwise. Unless - or so I assume - you want to run jacoco).

          This property will be set automatically if you run with JaCoCo so there's no need to specify it.
          I'm not sure we have what we need to run derbyall on weme6.2 with JaCoCo using an existing ant target, but I don't see fixing that as critical.

          Show
          Kristian Waagan added a comment - ML> I experimented, and it seems that indeed, because there is now and added property in functionTests/util/derby_tests.policy, we need to add that to the settings for running derbyall with weme6.2. Yes, looks like it. I think there's also a privilege missing for JaCoCo when running with derbyall, but that isn't as pressing since you have to opt in to run with JaCoCo. If the derbyall tests works for weme6.2 when specifying the two properties manually, I'm content with that. ML> This is not needed for running junit tests (with weme or otherwise. Unless - or so I assume - you want to run jacoco). This property will be set automatically if you run with JaCoCo so there's no need to specify it. I'm not sure we have what we need to run derbyall on weme6.2 with JaCoCo using an existing ant target, but I don't see fixing that as critical.
          Mike Matrigali made changes -
          Assignee Mike Matrigali [ mikem ]
          Hide
          Mike Matrigali added a comment -

          after changing our test running environment to deal with the new property all these errors have now gone away in the weme runs. Thanks Kristian and Myrna for help on this. I am going to close this issue.

          Show
          Mike Matrigali added a comment - after changing our test running environment to deal with the new property all these errors have now gone away in the weme runs. Thanks Kristian and Myrna for help on this. I am going to close this issue.
          Hide
          Mike Matrigali added a comment -

          junit errors fixed by 1448280 and derbyall errors fixed by changing harness to deal with the new property.

          Show
          Mike Matrigali added a comment - junit errors fixed by 1448280 and derbyall errors fixed by changing harness to deal with the new property.
          Mike Matrigali made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 10.10.0.0 [ 12321550 ]
          Resolution Fixed [ 1 ]
          Mike Matrigali made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Gavin made changes -
          Workflow jira [ 12762046 ] Default workflow, editable Closed status [ 12796951 ]

            People

            • Assignee:
              Mike Matrigali
              Reporter:
              Mike Matrigali
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development