Derby
  1. Derby
  2. DERBY-1618

store/BootAllTest.junit fails on with jdk13 based jvms

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.2.1.6
    • Fix Version/s: 10.2.1.6, 10.3.1.4
    • Component/s: Test
    • Labels:
      None
    • Environment:
      windows. (insane jars) 10.2.0.5 alpha - (426734)
    • Bug behavior facts:
      Regression, Regression Test Failure

      Description

      bootAll test fails on ibm131, wctme5.7.

                      • Diff file derbyall/storeall/storemore/BootAllTest.diff
          • Start: BootAllTest jdk1.3.1 storeall:storemore 2006-07-30 06:35:16 ***
            0 add
            > .F
            > There was 1 failure:
            > 1) testSettingBootAllPropertyWithHomePropertySet(org.apache.derbyTesting.functionTests.tests.store.BootAllTest)junit.framework.AssertionFailedError: The number of databases should be expected:<3> but was:<0>
            > FAILURES!!!
            > Tests run: 1, Failures: 1, Errors: 0
            Test Failed.
          • End: BootAllTest jdk1.3.1 storeall:storemore 2006-07-30 06:35:35 ***
      1. DERBY-1618_20060912.diff
        8 kB
        Myrna van Lunteren
      2. DERBY-1618_20060912.stat
        0.4 kB
        Myrna van Lunteren
      3. DERBY-1618_20060910.diff
        10 kB
        Myrna van Lunteren
      4. DERBY-1618_20060910.stat
        0.5 kB
        Myrna van Lunteren
      5. DERBY-1618_20060901.diff
        7 kB
        Myrna van Lunteren

        Activity

        Hide
        Myrna van Lunteren added a comment -

        mega-merged into 10.2 with 446709.

        Show
        Myrna van Lunteren added a comment - mega-merged into 10.2 with 446709.
        Hide
        Myrna van Lunteren added a comment -

        fixed in 10.3 - leaving open until this has gotten merged into 10.2.1.

        Show
        Myrna van Lunteren added a comment - fixed in 10.3 - leaving open until this has gotten merged into 10.2.1.
        Hide
        Suresh Thalamati added a comment -

        Committed DERBY-1618_20060912.diff to trunk on revision 443038.

        Show
        Suresh Thalamati added a comment - Committed DERBY-1618 _20060912.diff to trunk on revision 443038.
        Hide
        Myrna van Lunteren added a comment -

        Thx for looking at the patch and apologies for the unrelated changes that I left in.

        Attached patch - DERBY-1618_20060912.* - reverts those mistakenly left modified things - the BootAllTest.java should've been left untouched, and the externals for the 10.1 jars were modified for another bug.

        Apart from those, this patch is the same as the one from Sept 10, I haven't even done a sync in between.

        As the relevant parts have not changed (I did not run upgrade tests on this machine, so the externals setting didn't matter to my test run, and the println statements don't affect the BootAllTest unless you run with derby.tests.debug=true) I can't imagine the reverting of those 2 issues to impact the behavior, so I'm not rerunning the tests...

        Show
        Myrna van Lunteren added a comment - Thx for looking at the patch and apologies for the unrelated changes that I left in. Attached patch - DERBY-1618 _20060912.* - reverts those mistakenly left modified things - the BootAllTest.java should've been left untouched, and the externals for the 10.1 jars were modified for another bug. Apart from those, this patch is the same as the one from Sept 10, I haven't even done a sync in between. As the relevant parts have not changed (I did not run upgrade tests on this machine, so the externals setting didn't matter to my test run, and the println statements don't affect the BootAllTest unless you run with derby.tests.debug=true) I can't imagine the reverting of those 2 issues to impact the behavior, so I'm not rerunning the tests...
        Hide
        Suresh Thalamati added a comment -

        I reviewed the latest patch, it look good. I wanted to check with you couple of small changes in the diff file,
        before committing the patch.

        1) How is the following change in the diff is related to this bug fix ?
        Name: svn:externals

        + derby/10.1 https://svn.apache.org/repos/asf/db/derby/jars/10.1.3.1

        2) There are some new println() statements in BootAllTest.java , which are commented out. I typically remove such debug statements, once I find the problem. I am ok , if you would like to keep them there.

        +println(" start testSettingBootAllPropertyWithHomePropertySet ");
        + //println(" attributes length: " + attributes.length);
        //println(" attributes[" + i + "].name" + attributes[i].name);
        ...etc.

        Thanks
        /suresh

        Show
        Suresh Thalamati added a comment - I reviewed the latest patch, it look good. I wanted to check with you couple of small changes in the diff file, before committing the patch. 1) How is the following change in the diff is related to this bug fix ? Name: svn:externals derby/10.1 https://svn.apache.org/repos/asf/db/derby/jars/10.1.1.0 + derby/10.1 https://svn.apache.org/repos/asf/db/derby/jars/10.1.3.1 2) There are some new println() statements in BootAllTest.java , which are commented out. I typically remove such debug statements, once I find the problem. I am ok , if you would like to keep them there. +println(" start testSettingBootAllPropertyWithHomePropertySet "); + //println(" attributes length: " + attributes.length); //println(" attributes [" + i + "] .name" + attributes [i] .name); ...etc. Thanks /suresh
        Hide
        Myrna van Lunteren added a comment -

        Here's a patch - DERBY-1618_20060910.* - which tries to force the correct value for dataDirectory in the doInit() method of DirStorageFactory.
        I hope this is what was intended...Again I've run derbyall with jdk14 and ibm13 without seeing new failures.

        Show
        Myrna van Lunteren added a comment - Here's a patch - DERBY-1618 _20060910.* - which tries to force the correct value for dataDirectory in the doInit() method of DirStorageFactory. I hope this is what was intended...Again I've run derbyall with jdk14 and ibm13 without seeing new failures.
        Hide
        Suresh Thalamati added a comment -

        Thanks for working on this bug, Mryna. I briefly looked at the patch,
        this issue seems to be related to the DERBY-1296, fix for that seems to have
        addressed the problem on jdk14 jvms and above, but not on jvms version before that.

        Following code you copied to DirStorageFactory.java from DirStorageFactor4.java

        + String dir = dataDirectory;
        + if (canonicalName != null && path != null && home != null &&
        + !path.startsWith(home)) {
        + dir = canonicalName;

        is not the ideal fix. I think dataDirecroy , should get set to the correct
        value in the DirStorageFactory.doInit() throws IOException method.

        I think there is also another method in DirStorageFactory.java/DirStorageFactory4.java,
        where the database directory may be set to a wrong value.

        StorageFile newPersistentFile( String directoryName, String fileName)

        { return new DirFile( separatedDataDirectory + directoryName, fileName); }

        if the dataDirectory value is wrong for the method you are fixing , I am sure
        the above method also will get the wrong path. I think instead of adding checks
        for individual methods; dataDirectory should get set to the correct value
        in the doInit() method.

        Thanks for updating the GetPropertyInfoTest.java to print all the fields.

        Show
        Suresh Thalamati added a comment - Thanks for working on this bug, Mryna. I briefly looked at the patch, this issue seems to be related to the DERBY-1296 , fix for that seems to have addressed the problem on jdk14 jvms and above, but not on jvms version before that. Following code you copied to DirStorageFactory.java from DirStorageFactor4.java + String dir = dataDirectory; + if (canonicalName != null && path != null && home != null && + !path.startsWith(home)) { + dir = canonicalName; is not the ideal fix. I think dataDirecroy , should get set to the correct value in the DirStorageFactory.doInit() throws IOException method. I think there is also another method in DirStorageFactory.java/DirStorageFactory4.java, where the database directory may be set to a wrong value. StorageFile newPersistentFile( String directoryName, String fileName) { return new DirFile( separatedDataDirectory + directoryName, fileName); } if the dataDirectory value is wrong for the method you are fixing , I am sure the above method also will get the wrong path. I think instead of adding checks for individual methods; dataDirectory should get set to the correct value in the doInit() method. Thanks for updating the GetPropertyInfoTest.java to print all the fields.
        Hide
        Myrna van Lunteren added a comment -

        No further poking showed anything - that last bit in my previous comment should've gotten deleted.

        ibm131 results showed no new failures (encryption failed because of the really old jvm version I had on the machine, it does the same with other derby versions).

        Show
        Myrna van Lunteren added a comment - No further poking showed anything - that last bit in my previous comment should've gotten deleted. ibm131 results showed no new failures (encryption failed because of the really old jvm version I had on the machine, it does the same with other derby versions).
        Hide
        Myrna van Lunteren added a comment -

        Attaching a patch which I think addresses this issue.
        The patch changes these files:
        M java\engine\org\apache\derby\impl\io\DirStorageFactory.java
        M java\testing\org\apache\derbyTesting\functionTests\tests\lang\GetPropertyInfoTest.java
        M java\testing\org\apache\derbyTesting\functionTests\master\GetPropertyInfoTest.out

        It appeared to me that for some reason, with jdk131, in the situation invoked by the testSettingBootAllPropertyWithHomePropertySet() test in BootAllTest.java, when the DriverPropertyInfo.choices were accessed, the problem was because in BaseMonitor.java there were no elements found resulting from provider.getBootTimeServices(), which was because in StorageFactoryService the following:
        StorageFile properties = storageFactory.newStorageFile( PersistentService.PROPERTIES_NAME);
        if (!properties.exists())
        resulted in no properties files found. Here, however, I found that the properties with jdk14 had a path prepended, but jdk13 did not.
        And this was because of DirStorageFactory4 prepending the canonicalName, but DirStorageFactory not.

        So this patch copies a section of code of DirStorageFactory4.
        That fixes the failure in BootAllTest.java with jdk131 and ibm131. Derbyall passes with jdk14 (except for failure in CheckDataSource, which also fails in nightlies, so is unrelated). Still running with ibm131.

        If a reviewer has a suggestion of where this can be placed better, I'd be interested.

        I modified the test lang/GetPropertyInfoTest.java to access the choices, description, and required fields, but it didn't actually duplicate the problem in BootAllTest.java. But as that's in that test I thought it was unnecessary to add more...

        Poking further showed that th

        Show
        Myrna van Lunteren added a comment - Attaching a patch which I think addresses this issue. The patch changes these files: M java\engine\org\apache\derby\impl\io\DirStorageFactory.java M java\testing\org\apache\derbyTesting\functionTests\tests\lang\GetPropertyInfoTest.java M java\testing\org\apache\derbyTesting\functionTests\master\GetPropertyInfoTest.out It appeared to me that for some reason, with jdk131, in the situation invoked by the testSettingBootAllPropertyWithHomePropertySet() test in BootAllTest.java, when the DriverPropertyInfo.choices were accessed, the problem was because in BaseMonitor.java there were no elements found resulting from provider.getBootTimeServices(), which was because in StorageFactoryService the following: StorageFile properties = storageFactory.newStorageFile( PersistentService.PROPERTIES_NAME); if (!properties.exists()) resulted in no properties files found. Here, however, I found that the properties with jdk14 had a path prepended, but jdk13 did not. And this was because of DirStorageFactory4 prepending the canonicalName, but DirStorageFactory not. So this patch copies a section of code of DirStorageFactory4. That fixes the failure in BootAllTest.java with jdk131 and ibm131. Derbyall passes with jdk14 (except for failure in CheckDataSource, which also fails in nightlies, so is unrelated). Still running with ibm131. If a reviewer has a suggestion of where this can be placed better, I'd be interested. I modified the test lang/GetPropertyInfoTest.java to access the choices, description, and required fields, but it didn't actually duplicate the problem in BootAllTest.java. But as that's in that test I thought it was unnecessary to add more... Poking further showed that th
        Hide
        Myrna van Lunteren added a comment -

        modifying the title to move this failure onto the general radar.

        So far I've narrowed down the problem to when the test is accessing the field DriverPropertyInfo.choices.

        Note that I would've expected this access to get tested in the test lang/GetPropertyInfoTest.java, but it's not there - nor are the fields description or required.

        The problem appears that the services array isn't populated the same way with jdk131 as it is with jdk142 - the method startProviderService from java/engine/org/apache/derby/impl/services/monitor/BaseMonitor never gets called with jdk131.

        Show
        Myrna van Lunteren added a comment - modifying the title to move this failure onto the general radar. So far I've narrowed down the problem to when the test is accessing the field DriverPropertyInfo.choices. Note that I would've expected this access to get tested in the test lang/GetPropertyInfoTest.java, but it's not there - nor are the fields description or required. The problem appears that the services array isn't populated the same way with jdk131 as it is with jdk142 - the method startProviderService from java/engine/org/apache/derby/impl/services/monitor/BaseMonitor never gets called with jdk131.
        Hide
        Myrna van Lunteren added a comment -

        This second problem is now logged as DERBY-1785.

        Show
        Myrna van Lunteren added a comment - This second problem is now logged as DERBY-1785 .
        Hide
        Myrna van Lunteren added a comment -

        There are actually 2 failing behaviors with this test

        • jdk131/ibm131: 3 databases expected, was 3 (stack 1 below)
          But the databases are actually there.
        • wsdd5.6/wctme5.7/wctme5.7_foundation:
          AccessPropertylPermission framework read denied (stack 2 below)
          Odd because these environments don't run with security manager from the 'old' test harness, so not sure how it can give this error.

        stack1:
        There was 1 failure:
        1) testSettingBootAllPropertyWithHomePropertySet(org.apache.derbyTesting.functionTests.tests.store.BootAllTest)junit.framework.AssertionFailedError: The number of databases should be expected:<3> but was:<0>
        at org.apache.derbyTesting.functionTests.tests.store.BootAllTest.testSettingBootAllPropertyWithHomePropertySet(BootAllTest.java:129)
        at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76)

        stack 2:
        There was 1 error:
        1) testSettingBootAllPropertyWithHomePropertySet(org.apache.derbyTesting.functionTests.tests.store.BootAllTest)java.security.AccessControlException: Access denied (java.util.PropertyPermission framework read)
        at java.security.AccessController.checkPermission(AccessController.java:74)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:612)
        at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:366)
        at java.lang.System.getProperty(System.java:319)
        at java.lang.System.getProperty(System.java:301)
        at org.apache.derbyTesting.functionTests.util.TestUtil$1.run(TestUtil.java:177)
        at java.security.AccessController.doPrivileged(AccessController.java:147)
        at org.apache.derbyTesting.functionTests.util.TestUtil.getFramework(TestUtil.java:174)
        at org.apache.derbyTesting.functionTests.util.TestUtil.getDataSourcePrefix(TestUtil.java:391)
        at org.apache.derbyTesting.functionTests.util.TestUtil.getSimpleDataSource(TestUtil.java:330)
        at org.apache.derbyTesting.functionTests.util.TestUtil.getDataSource(TestUtil.java:324)
        at org.apache.derbyTesting.functionTests.util.TestDataSourceFactory.getDataSource(TestDataSourceFactory.java:47)
        at org.apache.derbyTesting.junit.TestConfiguration.openConnection(TestConfiguration.java:336)
        at org.apache.derbyTesting.junit.BaseJDBCTestCase.openConnection(BaseJDBCTestCase.java:197)
        at org.apache.derbyTesting.functionTests.tests.store.BootAllTest.setUp(BootAllTest.java:58)
        at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76)

        Show
        Myrna van Lunteren added a comment - There are actually 2 failing behaviors with this test jdk131/ibm131: 3 databases expected, was 3 (stack 1 below) But the databases are actually there. wsdd5.6/wctme5.7/wctme5.7_foundation: AccessPropertylPermission framework read denied (stack 2 below) Odd because these environments don't run with security manager from the 'old' test harness, so not sure how it can give this error. stack1: There was 1 failure: 1) testSettingBootAllPropertyWithHomePropertySet(org.apache.derbyTesting.functionTests.tests.store.BootAllTest)junit.framework.AssertionFailedError: The number of databases should be expected:<3> but was:<0> at org.apache.derbyTesting.functionTests.tests.store.BootAllTest.testSettingBootAllPropertyWithHomePropertySet(BootAllTest.java:129) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) stack 2: There was 1 error: 1) testSettingBootAllPropertyWithHomePropertySet(org.apache.derbyTesting.functionTests.tests.store.BootAllTest)java.security.AccessControlException: Access denied (java.util.PropertyPermission framework read) at java.security.AccessController.checkPermission(AccessController.java:74) at java.lang.SecurityManager.checkPermission(SecurityManager.java:612) at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:366) at java.lang.System.getProperty(System.java:319) at java.lang.System.getProperty(System.java:301) at org.apache.derbyTesting.functionTests.util.TestUtil$1.run(TestUtil.java:177) at java.security.AccessController.doPrivileged(AccessController.java:147) at org.apache.derbyTesting.functionTests.util.TestUtil.getFramework(TestUtil.java:174) at org.apache.derbyTesting.functionTests.util.TestUtil.getDataSourcePrefix(TestUtil.java:391) at org.apache.derbyTesting.functionTests.util.TestUtil.getSimpleDataSource(TestUtil.java:330) at org.apache.derbyTesting.functionTests.util.TestUtil.getDataSource(TestUtil.java:324) at org.apache.derbyTesting.functionTests.util.TestDataSourceFactory.getDataSource(TestDataSourceFactory.java:47) at org.apache.derbyTesting.junit.TestConfiguration.openConnection(TestConfiguration.java:336) at org.apache.derbyTesting.junit.BaseJDBCTestCase.openConnection(BaseJDBCTestCase.java:197) at org.apache.derbyTesting.functionTests.tests.store.BootAllTest.setUp(BootAllTest.java:58) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76)
        Hide
        Stan Bradbury added a comment -

        Same failure on SLES 9 using IBM131 SR10 - testing 10.2.1.0 beta

        Show
        Stan Bradbury added a comment - Same failure on SLES 9 using IBM131 SR10 - testing 10.2.1.0 beta

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development