JDK-6330699 : (se) VM dies when registering a SelectionKey on severals Selector
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 9.0pe
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_1
  • CPU: sparc
  • Submitted: 2005-09-29
  • Updated: 2011-03-17
  • Resolved: 2005-10-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
5.0u7Fixed 6 b57Fixed
Related Reports
Relates :  
SJSAS 9.0 (Sun Application Server) uses NIO for its HTTP Engine. Removing the workaround for 4953599 and running performance test on Solaris literally kill the VM, without any core/log. The problem seems to be that the C heap is corrupted, so lots of threads stack up trying to get native memory from the C heap. Meanwhile, the compiler thread detects the corruption in the C heap and tries to throw a signal, and the signal handler dies -- so either the entire process dies without a core, or the process hangs.

The attachement contains a pstack log showing the signal thread hanging, and the corresponding jstack output for that.

We've tested with 1.5.0_0X and the problem happens in all version.

EVALUATION -- Indeed there is a second issue. With a preliminary fix for 4621211 there is still random memory corruption. I've tracked it down to a timing bug in the DevPollSelectorProvider. With a preliminary for that the tests with the app server run to completion.

EVALUATION The submitter provided access to the machine and we located the fatal error logs and core file. The current crash is because java.io.File.list is used the non-MT safe readdir (it should be using readdir_r). This is tracked by 4621211. With this fixed we need to do further testing to see if that are other issues - the submitter has accumulated a varied selection of fatal error logs which suggest problems in other areas too.