Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6386648

Testbug: Solaris Regression tests are executed inconsistently on 64 bit platforms

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      b02
    • CPU:
      x86
    • OS:
      solaris

      Description

      Many tests (roughly 89) in the master 1.4.2_11 regression workspace at:
        /net/nightsvr.sfbay/export4/integration/1.4.2_11/j2se
      use the following syntax to decide 64 bit execution:

          if [ -f ${FILE_LOCATION}${FS}JDK64BIT -a ${OS} = "SunOS" -a `uname -p` = 'sparc' ]
          then
              BIT_FLAG="-d64"
          fi

      These may be searched for using:
        find /net/nightsvr.sfbay/export4/integration/1.4.2_11/j2se/test | grep -v SCCS | xargs grep '`uname -p` =' | grep JDK64BIT
      (The reason for using this exact search criteria is explained later)

      For example line 32 of:
      /net/nightsvr.sfbay/export4/integration/1.4.2_11/j2se/test/CTE_REGTEST/Generic/5002890/Test5002890.sh

      The above logic implies that if we have a JDK64BIT sentinel file in our home directory and are
      using SunOS on a sparc platform, the -d64 bit option will be used in this test.

      So for amd64 platforms, when I run these particular tests against the 64 bit JDK,
      I will _never_ get a 64 bit test invocation, because of the "sparc" check.
      This is even if I have specified -d64 as an option to my typical $JTREG_TOOL call

          export MYOPTION="-d64"
          $JTREG_TOOL -jdk:$JAVA_HOME $MYOPTION $CPA_OPTION $TESTBASE/test

      So there is some inconsistency between the sparc and amd64 bit platforms
      for running these tests, along with the misleading test configuration assumption.

      However, there is a more serious inconsistency between this group of tests and another.
      The other group of tests (roughly 370) use the following exact syntax:

          if [ -f ${FILE_LOCATION}${FS}JDK64BIT -a ${OS} = "SunOS" -a `uname -p`='sparc' ]
          then
              BIT_FLAG="-d64"
          fi

      These may be searched for using:
        find /net/nightsvr.sfbay/export4/integration/1.4.2_11/j2se/test | grep -v SCCS | xargs grep '`uname -p`=' | grep JDK64BIT

      For example line 40 of
      /net/nightsvr.sfbay/export4/integration/1.4.2_11/j2se/test/CTE_REGTEST/Generic/5032314/Test5032314.sh

      Note in particular the use of _no_ spaces in the token `uname -p`='sparc'
      This is a syntax error.

      eg. on AMD64:
      balboa 5.10 # uname -p
      i386

      The token "i386=sparc" always resolves to true in Bourne/Korn shell when used with [ ... ] construct.
      So even though I am not on Sparc architecture the buggy platform statement actually passes and applies the 64-bit Flag.

      These 370 odd tests are completely inconsistent with the first group.
      Paradoxically they may probably provide the desired test behaviour.
      I actually get a 64-bit VM invocation where the code semantics did
      not intend so, but the buggy syntax actually provided it.

      The -d64 bit tests did not actually raise many issues - I had 6 failures, mainly
      due to native tests where there was no appropriately named native
      64-bit library to link with.

      eg.
      /net/nightsvr.sfbay/export4/integration/1.4.2_11/j2se/test/CTE_REGTEST/Generic/4178050/Test4178050.sh

      So a number of aspects need to cleared up:

      1. Should AMD64 execution apply 64-bit option where user has configured for it in general?
      2. 370 odd tests need syntax correction for consistency with correctly coded tests
      3. 6 odd tests need more careful syntax to handle native library or other aspects that may complicate decision.
      4. All associated code should have appropriate comments to ease debug of these anomalies.
      5. There may be other issues in the regression codebase related to the improper bourne syntax for other decision logic. These will be bugged accordingly.
      Note: With regard to point 5 above, no other syntax problems apart from
      the sparc tests were observed in checks

        Attachments

          Activity

            People

            Assignee:
            asaha Abhijit Saha
            Reporter:
            wrockett Walter Rockett
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: