River
  1. River
  2. RIVER-230

(mux) SelectionManager catch Error block assumes getMessage() returns non-null

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: jtsk_2.0
    • Fix Version/s: River_2.1.2
    • Component/s: net_jini_jeri
    • Labels:
      None
    • Bugtraq ID:
      6332547

      Description

      Bugtraq ID 6332547

      com.sun.jini.jeri.internal.runtime.SelectionManager's waitForReadyKey method has the following catch block in order to work around JDK bug 4458268:

      		} catch (Error e) {
      		    if (e.getMessage().startsWith("POLLNVAL")) {
      			Thread.yield();
      			continue;		// work around 4458268
      		    } else {
      			throw e;
      		    }
      

      The problem is that Error.getMessage() may return null (in cases other than those that this code was intended to handle), in which case a NullPointerException will occur. Such a NullPointerException has been observed in the output of tests that cause an out-of-memory condition due to thread creation (in particular, the regression test /vob/qa/jtreg/net/jini/jeri/tcp/outOfThreads/OutOfThreads.java on Solaris 9):

      Oct 3, 2005 2:00:52 AM com.sun.jini.jeri.internal.runtime.SelectionManager$SelectLoop run
      WARNING: select loop throws
      java.lang.NullPointerException
      	at com.sun.jini.jeri.internal.runtime.SelectionManager.waitForReadyKey(SelectionManager.java:369)
      	at com.sun.jini.jeri.internal.runtime.SelectionManager.access$600(SelectionManager.java:80)
      	at com.sun.jini.jeri.internal.runtime.SelectionManager$SelectLoop.run(SelectionManager.java:287)
      	at com.sun.jini.thread.ThreadPool$Worker.run(ThreadPool.java:136)
      	at java.lang.Thread.run(Thread.java:595)
      (repeated)
      

      With the fix for 6304782, the select loop will continue after such an exception, but the type and stack trace of the original exception does not get logged properly (only the NPE gets logged).

      -------------

      Two examples of this phenomenon in test failures: (Sun internal URLs removed).

      In the second case, the VM terminated abruptly because of the out-of-memory condition anyway (not much we can do about that test failure mode?).

      In the first case, the harness timed out the test. Was that because I/O could not make progress because of the recurring select loop failures (perhaps also slowed by the loop throttling after repeated failures)?

      1. RIVER-230.patch
        0.6 kB
        Peter Jones

        Issue Links

          Activity

          Fred Oliver created issue -
          Fred Oliver made changes -
          Field Original Value New Value
          Description Bugtraq ID [6332547|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6332547]

          com.sun.jini.jeri.internal.runtime.SelectionManager's waitForReadyKey method has the following catch block in order to work around JDK bug 4458268:

          } catch (Error e) {
          if (e.getMessage().startsWith("POLLNVAL")) {
          Thread.yield();
          continue; // work around 4458268
          } else {
          throw e;
          }

          The problem is that Error.getMessage() may return null (in cases other than those that this code was intended to handle), in which case a NullPointerException will occur. Such a NullPointerException has been observed in the output of tests that cause an out-of-memory condition due to thread creation (in particular, the regression test /vob/qa/jtreg/net/jini/jeri/tcp/outOfThreads/OutOfThreads.java on Solaris 9):

          Oct 3, 2005 2:00:52 AM com.sun.jini.jeri.internal.runtime.SelectionManager$SelectLoop run
          WARNING: select loop throws
          java.lang.NullPointerException
          at com.sun.jini.jeri.internal.runtime.SelectionManager.waitForReadyKey(SelectionManager.java:369)
          at com.sun.jini.jeri.internal.runtime.SelectionManager.access$600(SelectionManager.java:80)
          at com.sun.jini.jeri.internal.runtime.SelectionManager$SelectLoop.run(SelectionManager.java:287)
          at com.sun.jini.thread.ThreadPool$Worker.run(ThreadPool.java:136)
          at java.lang.Thread.run(Thread.java:595)
          (repeated)

          With the fix for 6304782, the select loop will continue after such an exception, but the type and stack trace of the original exception does not get logged properly (only the NPE gets logged).

          -------------

          Two examples of this phenomenon in test failures: (Sun internal URLs removed).

          In the second case, the VM terminated abruptly because of the out-of-memory condition anyway (not much we can do about that test failure mode?).

          In the first case, the harness timed out the test. Was that because I/O could not make progress because of the recurring select loop failures (perhaps also slowed by the loop throttling after repeated failures)?
          Bugtraq ID [6332547|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6332547]

          com.sun.jini.jeri.internal.runtime.SelectionManager's waitForReadyKey method has the following catch block in order to work around JDK bug 4458268:

          {noformat}
          } catch (Error e) {
          if (e.getMessage().startsWith("POLLNVAL")) {
          Thread.yield();
          continue; // work around 4458268
          } else {
          throw e;
          }
          {noformat}

          The problem is that Error.getMessage() may return null (in cases other than those that this code was intended to handle), in which case a NullPointerException will occur. Such a NullPointerException has been observed in the output of tests that cause an out-of-memory condition due to thread creation (in particular, the regression test /vob/qa/jtreg/net/jini/jeri/tcp/outOfThreads/OutOfThreads.java on Solaris 9):

          {noformat}
          Oct 3, 2005 2:00:52 AM com.sun.jini.jeri.internal.runtime.SelectionManager$SelectLoop run
          WARNING: select loop throws
          java.lang.NullPointerException
          at com.sun.jini.jeri.internal.runtime.SelectionManager.waitForReadyKey(SelectionManager.java:369)
          at com.sun.jini.jeri.internal.runtime.SelectionManager.access$600(SelectionManager.java:80)
          at com.sun.jini.jeri.internal.runtime.SelectionManager$SelectLoop.run(SelectionManager.java:287)
          at com.sun.jini.thread.ThreadPool$Worker.run(ThreadPool.java:136)
          at java.lang.Thread.run(Thread.java:595)
          (repeated)
          {noformat}

          With the fix for 6304782, the select loop will continue after such an exception, but the type and stack trace of the original exception does not get logged properly (only the NPE gets logged).

          -------------

          Two examples of this phenomenon in test failures: (Sun internal URLs removed).

          In the second case, the VM terminated abruptly because of the out-of-memory condition anyway (not much we can do about that test failure mode?).

          In the first case, the harness timed out the test. Was that because I/O could not make progress because of the recurring select loop failures (perhaps also slowed by the loop throttling after repeated failures)?
          Peter Jones made changes -
          Assignee Peter Jones [ peter.jones ]
          Fix Version/s AR2 [ 12312604 ]
          Peter Jones made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Hide
          Peter Jones added a comment -

          Attached patch for this issue.

          Show
          Peter Jones added a comment - Attached patch for this issue.
          Peter Jones made changes -
          Attachment RIVER-230.patch [ 12379594 ]
          Peter Jones made changes -
          Resolution Fixed [ 1 ]
          Status In Progress [ 3 ] Resolved [ 5 ]
          Peter Firmstone made changes -
          Link This issue is related to RIVER-304 [ RIVER-304 ]
          Peter Firmstone made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Peter Jones
              Reporter:
              Fred Oliver
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development