JDK-8050499 : (ch) NativeSignal.signal fails with error 316 on OS X
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 8u20
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • CPU: x86
  • Submitted: 2014-07-15
  • Updated: 2016-01-14
  • Resolved: 2016-01-05
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.
9 b101Fixed
Related Reports
Relates :  
Relates :  
After this fix for JDK-7133499 the attached test case no longer works on OS X with Java 1.8.0_20-ea-b21. It fails with the following exception: 

java.io.IOException: Unknown error: 316 
at sun.nio.ch.NativeThread.signal(Native Method) 
at sun.nio.ch.DatagramChannelImpl.implCloseSelectableChannel(DatagramChannelImpl.java:1012) 
at java.nio.channels.spi.AbstractSelectableChannel.implCloseChannel(AbstractSelectableChannel.java:234) 
at java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:115) 
at UDPListenerTest$ListenerThread.terminate(UDPListenerTest.java:70) 
at UDPListenerTest.shutdown(UDPListenerTest.java:30) 
at UDPListenerTest.main(UDPListenerTest.java:45) 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
at java.lang.reflect.Method.invoke(Method.java:483) 
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Review thread: http://mail.openjdk.java.net/pipermail/nio-dev/2016-January/003447.html

SQE is ok to defer this bug from 8u20

This is not a stopper for 8u20. The short term plan for this is to handle the thread termination case in JDK 9, let it bake for a bit and then we can consider whether to back-port. More longer term then we need improve this area (the underlying issue goes back to JDK 1.4 and is not OS X specific).

I'm assuming this is NOT a stopper for 8u20. Can you request 8u20-defer-request and get SQE-OK - if my assumption is correct.

No need for additional tracing now, I think the only thing we can do in the short term here is have signal handle the case that the thread has exited (which is what is happening here). This doesn't explain the 316 but does explain the intermittent "no such process" error.

Do you still want me to produce the trace you asked for?

I tracked down a system running 10.9 and the test case does demonstrate the issue.

Thanks for new test case, unfortunately I've still been unable to duplicate this (same two machines running 10.7.x and 10.8.5). The environment section on the issue says 10.9.3 so I need to track down a machine with 10.9 to see if I can duplicate it. (Leonid, I don't know this is your own build, if it is then it would be useful if you should put a trace message in Java_sun_nio_ch_DatagramChannelImpl_receive0 to print out the value of thr_self, and another in Java_sun_nio_ch_NativeThread_signal to indicate the thread that is being signaled).

I haven't been able to duplicate this on 10.7 or 10.8.5 yet.

I believe I was able to come with a test case that reproduces the problem when ran via command line. It might take a few tries to see the exception, though. Check UDPListenerTest2.java.