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

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



    • Subcomponent:
    • Resolved In Build:
    • CPU:
    • OS:


      Many tests (roughly 89) in the master 1.4.2_11 regression workspace at:
      use the following syntax to decide 64 bit execution:

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

      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:

      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"

      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' ]

      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

      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

      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.


      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




            asaha Abhijit Saha
            wrockett Walter Rockett
            0 Vote for this issue
            0 Start watching this issue