Derby
  1. Derby
  2. DERBY-5558

NullPointerException in store.RecoveryTest launchRecoveryInsert and failure in testBasicRecovery with weme 6.2

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.9.1.0
    • Fix Version/s: 10.9.1.0
    • Component/s: Test
    • Labels:
      None
    • Environment:
      windows XP with IBM's weme6.2 (CDC Foundation 1.1)
    • Bug behavior facts:
      Regression Test Failure

      Description

      Since November 27 the weme 6.2 tests have reported the following failure and error:

      1) testBasicRecovery(org.apache.derbyTesting.functionTests.tests.store.RecoveryTest)junit.framework.AssertionFailedError: expectedExitValue:0 does not match exitValue:1
      expected output strings:
      [0]OK (1 test)
      actual output:<STDOUT> .E
      Time: 0.156
      There was 1 error:
      1) launchRecoveryInsert(org.apache.derbyTesting.functionTests.tests.store.RecoveryTest)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.security.Policy.getPolicy(Policy.java:49)
      at org.apache.derbyTesting.junit.SecurityManagerSetup$1.run(SecurityManagerSetup.java:191)
      at java.security.AccessController.doPrivileged(AccessController.java:204)
      at org.apache.derbyTesting.junit.SecurityManagerSetup.installSecurityManager(SecurityManagerSetup.java:185)
      at org.apache.derbyTesting.junit.SecurityManagerSetup.installSecurityManager(SecurityManagerSetup.java:145)
      at org.apache.derbyTesting.junit.TestConfiguration.defaultSecurityManagerSetup(TestConfiguration.java:1904)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)

      FAILURES!!!
      Tests run: 1, Failures: 0, Errors: 1

      <END STDOUT>
      <STDERR><END STDERR>
      expected:<0> but was:<1>
      at junit.framework.AssertionFailedError.<init>(AssertionFailedError.java:13)
      at org.apache.derbyTesting.junit.BaseTestCase.assertExecJavaCmdAsExpected(BaseTestCase.java:516)
      at org.apache.derbyTesting.junit.BaseTestCase.assertLaunchedJUnitTestMethod(BaseTestCase.java:855)
      at org.apache.derbyTesting.functionTests.tests.store.RecoveryTest.testBasicRecovery(RecoveryTest.java:89)
      at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:195)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:116)
      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)

      FAILURES!!!
      Tests run: 6526, Failures: 1, Errors: 0

      ---------------
      This started occurring with revision 1206656.

      The change since the revision previous to that was:
      SUBVERSION LOG FROM 1206392 TO 1206656:
      ------------------------------------------------------------------------
      r1206409 | kahatlen | 2011-11-26 00:11:10 -0800 (Sat, 26 Nov 2011) | 4 lines

      DERBY-5514: SecureServerTest (and others) don't play nice with EMMA: AccessControlException

      Grant permissions to write coverage data to all code bases, to work
      around EMMA's lack of doPrivileged blocks.
      ------------------------------------------------------------------------

      I assume this is because we run weme6.2 with the following emma flag:
      -Demma.active=""

      We've been running with this set for a very long time, I cannot remember why.
      I'll see if I can find that out, at least.

      1. DERBY-5558.diff
        0.9 kB
        Myrna van Lunteren

        Activity

        Hide
        Myrna van Lunteren added a comment -

        This test no longer fails with weme 6.2 after adding the jvm-issue workaround.

        Show
        Myrna van Lunteren added a comment - This test no longer fails with weme 6.2 after adding the jvm-issue workaround.
        Hide
        Myrna van Lunteren added a comment -

        I committed the patch with revision 1227016.

        Show
        Myrna van Lunteren added a comment - I committed the patch with revision 1227016.
        Hide
        Knut Anders Hatlen added a comment -

        It looks like this test doesn't have any problems when emma.active is set on other platforms (it typically gets set automatically by SecurityManagerSetup if required), so it's probably fine to limit the workaround to j9 only.

        Show
        Knut Anders Hatlen added a comment - It looks like this test doesn't have any problems when emma.active is set on other platforms (it typically gets set automatically by SecurityManagerSetup if required), so it's probably fine to limit the workaround to j9 only.
        Hide
        Myrna van Lunteren added a comment -

        Attaching a patch that for j9, checks for emma.active property and if not null, add it to the command to be forked.
        This works around the problem with IBM j9.

        Or should we check for emma.active always, not just for j9?

        Show
        Myrna van Lunteren added a comment - Attaching a patch that for j9, checks for emma.active property and if not null, add it to the command to be forked. This works around the problem with IBM j9. Or should we check for emma.active always, not just for j9?
        Hide
        Myrna van Lunteren added a comment -

        The need for setting emma.active="" appears to be because of a bug in weme - which is unlikely to get fixed at this point in time.
        I tried running derbyall without emma.active="" and found a lot more of these NullPointerExceptions, so I think the problem is that store.RecoveryTest attempts to launch a new instance of the jvm, and perhaps somehow it's not propogating the emma.active setting.

        Show
        Myrna van Lunteren added a comment - The need for setting emma.active="" appears to be because of a bug in weme - which is unlikely to get fixed at this point in time. I tried running derbyall without emma.active="" and found a lot more of these NullPointerExceptions, so I think the problem is that store.RecoveryTest attempts to launch a new instance of the jvm, and perhaps somehow it's not propogating the emma.active setting.

          People

          • Assignee:
            Myrna van Lunteren
            Reporter:
            Myrna van Lunteren
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development