Derby
  1. Derby
  2. DERBY-4739

test hang in Suites.all starting derbynet.SSLTest on Mac OS X 10.6

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 10.7.1.1
    • Fix Version/s: None
    • Component/s: Test
    • Environment:
      Mac OS X 10.6

      java version "1.6.0_20"
      Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
      Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode)

    • Urgency:
      Urgent
    • Bug behavior facts:
      Regression Test Failure

      Description

      My suites.All run on OS X 10.6 hung after the following
      testSysinfoMethod used 15 ms .
      testSysinfoLocale used 447 ms

      The following processes are running so I assume the issue is actually with SSLTest, which is the next up.

      Katherine-Marsdens-iMac:test kmarsden$ ps -ef | grep java
      501 53221 21233 0 0:00.00 ttys000 0:00.00 grep java
      501 52832 52830 0 0:06.18 ttys001 0:41.73 /usr/bin/java -Dderby.tests.trace=true -XX:MaxPermSize=128M -Xmx1024M -Xms512M -DderbyTesting.oldReleasePath=/Users/kmarsden/Derby/svn/svnreleases/jars junit.textui.TestRunner org.apache.derbyTesting.functionTests.suites.All
      501 52901 52832 0 0:01.57 ttys001 0:05.66 /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bin/java -classpath /Users/kmarsden/Derby/svn/trunk/jars/sane/derbyrun.jar:/Users/kmarsden/Derby/svn/trunk/jars/sane/derbyTesting.jar:/Users/kmarsden/Derby/svn/trunk/tools/java/junit.jar:/Users/kmarsden/Derby/svn/trunk/tools/java/jakarta-oro-2.0.8.jar -Djavax.net.ssl.keyStore=extinout/SSLTestServerKey.key -Djavax.net.ssl.keyStorePassword=qwerty org.apache.derby.drda.NetworkServerControl start -h localhost -p 1527 -ssl basic
      Katherine-Marsdens-iMac:test kmarsden$

      The derby.log which actually is in the test start directory shows the server started.

      Katherine-Marsdens-iMac:test kmarsden$ cat derby.log
      2010-07-08 19:37:42.485 GMT : Apache Derby Network Server - 10.7.0.0 alpha - (959181M) started and ready to accept SSL connections on port 1527

      I am trying to figure out how to get a thread dump. I have so far tried kill -QUIT and <ctrl> \ in the terminal screen and <command> \.
      Once I get that I will try to run the test by itself.

      1. sslserver52901.txt
        5 kB
        Kathey Marsden
      2. suitesall52832.txt
        9 kB
        Kathey Marsden

        Issue Links

          Activity

          Hide
          Kathey Marsden added a comment -

          jstack <pid> gives stack dumps. Here they are for the server and the suites.All process.

          The test is hung pinging the server, waiting for a response.

          ava.lang.Thread.State: RUNNABLE
          at java.net.SocketInputStream.socketRead0(Native Method)
          at java.net.SocketInputStream.read(SocketInputStream.java:129)
          at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
          at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
          at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:789)

          • locked <1094fe868> (a java.lang.Object)
            at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1120)
          • locked <1094fe810> (a java.lang.Object)
            at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1147)
            at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1131)
            at org.apache.derby.impl.drda.NetworkServerControlImpl$6.run(NetworkServerControlImpl.java:2523)
            at java.security.AccessController.doPrivileged(Native Method)
            at org.apache.derby.impl.drda.NetworkServerControlImpl.setUpSocket(NetworkServerControlImpl.java:250\
            2)
            at org.apache.derby.impl.drda.NetworkServerControlImpl.ping(NetworkServerControlImpl.java:1188)
            at org.apache.derby.drda.NetworkServerControl.ping(NetworkServerControl.java:395)
            at org.apache.derbyTesting.junit.NetworkServerTestSetup.pingForServerUp(NetworkServerTestSetup.java:\
            565)
            at org.apache.derbyTesting.junit.NetworkServerTestSetup.pingForServerStart(NetworkServerTestSetup.ja\
            va:634)
            at org.apache.derbyTesting.junit.NetworkServerTestSetup.setçUp(NetworkServerTestSetup.java:195)
            at junit.extensions.TestSetup$1.protect(TestSetup.java:20)

          The server has no DRDAConnThread processing the request.

          I think the server is still responding, because if I try to ping it I get:

          Katherine-Marsdens-iMac:system kmarsden$ java org.apache.derby.drda.NetworkServerControl ping
          2010-07-08 22:13:21.612 GMT : Invalid reply header from network server: Invalid string . Plaintext connection attempt to an SSL enabled server

          Show
          Kathey Marsden added a comment - jstack <pid> gives stack dumps. Here they are for the server and the suites.All process. The test is hung pinging the server, waiting for a response. ava.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293) at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:789) locked <1094fe868> (a java.lang.Object) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1120) locked <1094fe810> (a java.lang.Object) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1147) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1131) at org.apache.derby.impl.drda.NetworkServerControlImpl$6.run(NetworkServerControlImpl.java:2523) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derby.impl.drda.NetworkServerControlImpl.setUpSocket(NetworkServerControlImpl.java:250\ 2) at org.apache.derby.impl.drda.NetworkServerControlImpl.ping(NetworkServerControlImpl.java:1188) at org.apache.derby.drda.NetworkServerControl.ping(NetworkServerControl.java:395) at org.apache.derbyTesting.junit.NetworkServerTestSetup.pingForServerUp(NetworkServerTestSetup.java:\ 565) at org.apache.derbyTesting.junit.NetworkServerTestSetup.pingForServerStart(NetworkServerTestSetup.ja\ va:634) at org.apache.derbyTesting.junit.NetworkServerTestSetup.setçUp(NetworkServerTestSetup.java:195) at junit.extensions.TestSetup$1.protect(TestSetup.java:20) The server has no DRDAConnThread processing the request. I think the server is still responding, because if I try to ping it I get: Katherine-Marsdens-iMac:system kmarsden$ java org.apache.derby.drda.NetworkServerControl ping 2010-07-08 22:13:21.612 GMT : Invalid reply header from network server: Invalid string . Plaintext connection attempt to an SSL enabled server
          Hide
          Kathey Marsden added a comment -

          I confirmed the test hangs when run stand-alone. Lily pointed me to this link. I don't know much about SSL. Perhaps something special needs to be don for Mac OSX 10.6

          http://developer.apple.com/internet/serverside/modssl.html

          Show
          Kathey Marsden added a comment - I confirmed the test hangs when run stand-alone. Lily pointed me to this link. I don't know much about SSL. Perhaps something special needs to be don for Mac OSX 10.6 http://developer.apple.com/internet/serverside/modssl.html
          Hide
          Kathey Marsden added a comment -

          Lily and I looked at this for a few minutes the other day. A few things we noted:
          Since the test does not run with classes a work around for running Suites.All might be to run tests with classpath set to poiint to classes instead of the jars and the test will be skipped.

          We tried to fire the test up in the debugger but since the server process is spawned we couldn't see what was happening there. The thread dumps show that there is no DRDAConnThread on the server side waiting to handle the request, so I am guessing some unlogged exception caused the session creation to fail and somehow that exception was lost. In ClientThread.java it looks like all exceptions that occur during parent.addSession(clientSocket) get caught and reported with parent.consoleExceptionPrintTrace(ie) except but I don't know how the PrintWriter is set for the test, so maybe are getting lost somehow. I guess I would start with changing consoleExceptiPrintTrace to just print to System.out to make sure no exception is lost.

          Show
          Kathey Marsden added a comment - Lily and I looked at this for a few minutes the other day. A few things we noted: Since the test does not run with classes a work around for running Suites.All might be to run tests with classpath set to poiint to classes instead of the jars and the test will be skipped. We tried to fire the test up in the debugger but since the server process is spawned we couldn't see what was happening there. The thread dumps show that there is no DRDAConnThread on the server side waiting to handle the request, so I am guessing some unlogged exception caused the session creation to fail and somehow that exception was lost. In ClientThread.java it looks like all exceptions that occur during parent.addSession(clientSocket) get caught and reported with parent.consoleExceptionPrintTrace(ie) except but I don't know how the PrintWriter is set for the test, so maybe are getting lost somehow. I guess I would start with changing consoleExceptiPrintTrace to just print to System.out to make sure no exception is lost.
          Hide
          Rick Hillegas added a comment -

          For the record, the tests also hang for me using Java 6 on Mac OS X. The tests run fine with Java 5.

          Show
          Rick Hillegas added a comment - For the record, the tests also hang for me using Java 6 on Mac OS X. The tests run fine with Java 5.
          Hide
          Myrna van Lunteren added a comment -

          I'm marking this Invalid, judging by the 10.8.2.0 and later platform test results, the tests passed on Mac OSX 10.6.8, with
          Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3515).
          see: http://wiki.apache.org/db-derby/TenEightTwoPlatformTesting
          So if this is still occurring with Apple's 1.6, there is likely something wrong with it, and the work-around would be to use Oracle's JVM.

          Show
          Myrna van Lunteren added a comment - I'm marking this Invalid, judging by the 10.8.2.0 and later platform test results, the tests passed on Mac OSX 10.6.8, with Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3515). see: http://wiki.apache.org/db-derby/TenEightTwoPlatformTesting So if this is still occurring with Apple's 1.6, there is likely something wrong with it, and the work-around would be to use Oracle's JVM.

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development