Derby
  1. Derby
  2. DERBY-4168

testMkdirsInvalidAbsolute(org.apache.derbyTesting.unitTests.junit.VirtualFileTest)junit.framework.AssertionFailedError on Zos

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Invalid
    • Affects Version/s: 10.5.1.1
    • Fix Version/s: None
    • Component/s: Test
    • Labels:
      None
    • Environment:
      Zos IBM 1.6 pmz3160sr2ifx-20081021_01
    • Bug behavior facts:
      Regression Test Failure

      Description

      On Zos with 10.5.1.1 (RC2) and IBM 1.6 pmz3160sr2ifx-20081021_01 I saw this failure. I did not see it with RC1 with the 64bit jvm.

      1) testMkdirsInvalidAbsolute(org.apache.derbyTesting.unitTests.junit.VirtualFileTest)junit.framework.AssertionFailedErro
      r
      at org.apache.derbyTesting.unitTests.junit.VirtualFileTest.testMkdirsInvalidAbsolute(VirtualFileTest.java:94)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:105)

        Activity

        Kathey Marsden created issue -
        Kathey Marsden made changes -
        Field Original Value New Value
        Summary  testMkdirsInvalidAbsolute(org.apache.derbyTesting.unitTests.junit.VirtualFileTest)junit.framework.AssertionFailedError on zZos  testMkdirsInvalidAbsolute(org.apache.derbyTesting.unitTests.junit.VirtualFileTest)junit.framework.AssertionFailedError on Zos
        Hide
        Kristian Waagan added a comment -

        I don't have Zos available, and I don't know much about it.
        Can anyone step through the code in VirtualFile.mkdir and DataStore.createEntry to determine why the entry isn't added?
        What does the root of a Zos file system look like? (i.e. is it '/'?)

        Show
        Kristian Waagan added a comment - I don't have Zos available, and I don't know much about it. Can anyone step through the code in VirtualFile.mkdir and DataStore.createEntry to determine why the entry isn't added? What does the root of a Zos file system look like? (i.e. is it '/'?)
        Hide
        Kathey Marsden added a comment -

        Thanks Kristian for your interest in this issue. I didn't see this fail when I ran on zOs with the 64bit jvm on RC1. Is the test new since then? I don't have a debugger on z but will try to debug this week with some printlns. The root of the file system in the shell I am using is '/'.

        Show
        Kathey Marsden added a comment - Thanks Kristian for your interest in this issue. I didn't see this fail when I ran on zOs with the 64bit jvm on RC1. Is the test new since then? I don't have a debugger on z but will try to debug this week with some printlns. The root of the file system in the shell I am using is '/'.
        Hide
        Kristian Waagan added a comment -

        The test was there in RC1 as well, but code changes were made between RC1 and RC2.
        The test seems to fail only on Zos though. It fails very early on, and this is what should happen:
        1) Get a DataStore where the file system root exists ('/'?).
        2) Obtain a VirtualFile pointing at '/directory'.
        3) Create the directory '/directory'.

        For 3 to succeed, the root has to exist.
        VirtualFile.mkdir() can fail for two reasons;
        a) The path already exists.
        b) DataStore is unable to add/create the directory.
        (for several reasons, see DataStore.createEntry)

        Note that java.io.File is used.

        Show
        Kristian Waagan added a comment - The test was there in RC1 as well, but code changes were made between RC1 and RC2. The test seems to fail only on Zos though. It fails very early on, and this is what should happen: 1) Get a DataStore where the file system root exists ('/'?). 2) Obtain a VirtualFile pointing at '/directory'. 3) Create the directory '/directory'. For 3 to succeed, the root has to exist. VirtualFile.mkdir() can fail for two reasons; a) The path already exists. b) DataStore is unable to add/create the directory. (for several reasons, see DataStore.createEntry) Note that java.io.File is used.
        Hide
        Kathey Marsden added a comment -

        I put some printlns in the code and am seeing some pretty strange behavior.
        I copied the relevant source to the z/OS machine so I could make changes and compile there.
        I copied the files under org/apache/derby/impl/io/vfmem and necessary supporting files.
        My CLASSPATH contains ., junit.jar and derbyTesting.jar from RC2. The very strange thing
        is that if I copy VirtualFileTest.java to the z/OS machine and use the locally compiled copy, the
        test passes and the problem does not reproduce, but pointing to the RC2 derbyTesting.jar I
        can make the problem happen.

        I have printlns in DataStore on entry to createEntry right after npath is determined, when a parent is added to parents,
        and when a lookup for a parent is not in files.

        Here is the output I see when the test passes (test built locally on z/OS).

        testMkdirsInvalidAbsolute createEntry: iPath=/ nPath=/
        createEntry: iPath=/directory nPath=/directory
        Adding parent /
        createEntry: iPath=/directory/afile nPath=/directory/afile
        Adding parent /directory
        Adding parent /
        [snip other irrelevant output]
        used 22 ms .

        and when it fails, pointing to derbyTesting.jar
        testMkdirsInvalidAbsolute createEntry: iPath=/directory nPath=/directory
        Adding parent /
        Entry for parent:/is not in files
        used 32 ms F.

        In the failing case we never see a createEntry for /, but the test clearly and unconditionally
        calls store.createEntry(java.io.File.separator, true) in getStore()

        Tomorrow I will try to rebuild the testing jar with some printlns and see what is going on. I tried to run with -Xint to make sure it is not a JIT issue.

        Show
        Kathey Marsden added a comment - I put some printlns in the code and am seeing some pretty strange behavior. I copied the relevant source to the z/OS machine so I could make changes and compile there. I copied the files under org/apache/derby/impl/io/vfmem and necessary supporting files. My CLASSPATH contains ., junit.jar and derbyTesting.jar from RC2. The very strange thing is that if I copy VirtualFileTest.java to the z/OS machine and use the locally compiled copy, the test passes and the problem does not reproduce, but pointing to the RC2 derbyTesting.jar I can make the problem happen. I have printlns in DataStore on entry to createEntry right after npath is determined, when a parent is added to parents, and when a lookup for a parent is not in files. Here is the output I see when the test passes (test built locally on z/OS). testMkdirsInvalidAbsolute createEntry: iPath=/ nPath=/ createEntry: iPath=/directory nPath=/directory Adding parent / createEntry: iPath=/directory/afile nPath=/directory/afile Adding parent /directory Adding parent / [snip other irrelevant output] used 22 ms . and when it fails, pointing to derbyTesting.jar testMkdirsInvalidAbsolute createEntry: iPath=/directory nPath=/directory Adding parent / Entry for parent:/is not in files used 32 ms F. In the failing case we never see a createEntry for /, but the test clearly and unconditionally calls store.createEntry(java.io.File.separator, true) in getStore() Tomorrow I will try to rebuild the testing jar with some printlns and see what is going on. I tried to run with -Xint to make sure it is not a JIT issue.
        Hide
        Kathey Marsden added a comment -

        Closing this issue as invalid. There seemed to be some miniscule corruption of the derbyTesting.jar as I sent ftp to the z/OS machine. The size and cmp showed a difference in the derbyTesting.jar. ( I am surprised it worked as well as it did! I thought ftp checked for such things.) I resent the jar and verified the file size and the test ran fine.

        Show
        Kathey Marsden added a comment - Closing this issue as invalid. There seemed to be some miniscule corruption of the derbyTesting.jar as I sent ftp to the z/OS machine. The size and cmp showed a difference in the derbyTesting.jar. ( I am surprised it worked as well as it did! I thought ftp checked for such things.) I resent the jar and verified the file size and the test ran fine.
        Kathey Marsden made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Invalid [ 6 ]
        Hide
        Kathey Marsden added a comment -

        Ah, I see, this was actually user error. I see the size on my problematic derbyTesting.jar matches RC1, when I transferred the new files over I must have neglected to cd over to the test directory and transfer derbyTesting.jar over. I should have cleared the jars out from my RC1 run to avoid the possibility for such a mistake. Sorry to waste everyone's time.

        Show
        Kathey Marsden added a comment - Ah, I see, this was actually user error. I see the size on my problematic derbyTesting.jar matches RC1, when I transferred the new files over I must have neglected to cd over to the test directory and transfer derbyTesting.jar over. I should have cleared the jars out from my RC1 run to avoid the possibility for such a mistake. Sorry to waste everyone's time.
        Hide
        Kristian Waagan added a comment -

        Well, good to know what was going on
        Closing the issue.

        Show
        Kristian Waagan added a comment - Well, good to know what was going on Closing the issue.
        Kristian Waagan made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Gavin made changes -
        Workflow jira [ 12461094 ] Default workflow, editable Closed status [ 12800202 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Kathey Marsden
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development