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

PIT b96: sec regression test sun/security/mscapi/RSAEncryptDecrypt.sh failed

    Details

    • Subcomponent:
    • Resolved In Build:
      b97
    • CPU:
      x86
    • OS:
      windows
    • Verification:
      Verified

      Description

      In mustang PIT b96 , test (j2se) sun/security/mscapi/RSAEncryptDecrypt.sh failed with jtreg running on windows ( this test is windows-only ).

      If run with jtreg , this test thrown exception as following:
      Exception in thread "main" java.security.KeyException: The system cannot find the path specified.

      at sun.security.mscapi.RSAKeyPairGenerator.generateRSAKeyPair(Native Method)
      at sun.security.mscapi.RSAKeyPairGenerator.generateKeyPair(RSAKeyPairGenerator.java:73)
      at java.security.KeyPairGenerator$Delegate.generateKeyPair(KeyPairGenerator.java:650)
      at RSAEncryptDecrypt.main(RSAEncryptDecrypt.java:18)
      result: Failed. Execution failed: exit code 1

      The test works fine in standalone mode : thrown no exception if run the RSAEncryptDecrypt.java in standalone or run RSAEncryptDecrypt.sh in standalone .

      But we should get the test fixed since we normally run the test with jtreg.

      Result can be found at :
      http://sqeweb.sfbay/sec/status/pit_6.0_dtf_results/sec_6.0_regression-reg_windows-i586-2006-08-09-16-10-15-0209/
      I was not as vigilant as I should have been. The nightly builds have been experiencing this error as well. I chalked that up to being run via ATAMAN's remote login software, so I don't think that is the root of the problem.

      I have duplicated this on the SQE test machine, our build machine (sheen), and on my laptop. The test and my machine are windows XP machines, the build machine is windows-2000. I used the dtftest account on the test machine, my local administrator account on my machine, and a regular user on sheen. I ran on the console on all machines, via VNC in the case of the remote machines. I wouldn't expect that to cause any problems.

      I was running using the FCS of JTREG 2.1.6.

      Without JTREG, the test runs just fine.

      To remove the chance this was a shell environment problem, I made the .java file the actual driver (moved the @ keywords to the java file), but still the error persisted. Definitely have a problem with the jtreg. ###@###.### might need to be called in on this one, if you can't figure it out, Vinnie.

        Attachments

          Activity

            People

            • Assignee:
              wetmore Bradford Wetmore
              Reporter:
              amlu Amy Lu
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Imported:
                Indexed: