|
Quick Lists
|
|
Bug ID:
|
6380091
|
|
Votes
|
1
|
|
Synopsis
|
IOException/SIGSEGV occurs during SocketChannel.close processing.
|
|
Category
|
java:classes_nio
|
|
Reported Against
|
rc
|
|
Release Fixed
|
mustang(b73),
5.0u8(b01) (Bug ID:2134804)
|
|
State
|
10-Fix Delivered,
bug
|
|
Priority:
|
2-High
|
|
Related Bugs
|
6419424
,
2137628
,
6445262
,
6691969
|
|
Submit Date
|
02-FEB-2006
|
|
Description
|
The customer is getting following 3 errors at SocketChannel.close processing.
Case1: SIGSEGV occurs and VM crashes.
(See hs_err_pid14024.log, but core was not generated.)
Case2: "IOException: No such file or directory" occurs.
Case3: "IOException: Thread signal failed" occurs
Posted Date : 2006-02-02 08:35:16.0
|
|
Work Around
|
N/A
|
|
Evaluation
|
The bug is that a non-existant thread is being signalled. The issue is intermittent and the failure modes vary because the pthread_t of a terminated thread is passed to pthread_kill. The reason this is happening is because SocketChannelImpl's connect method isn't resetting the readerThread so when the channel is closed it attempts to signal the reader. The test case provokes this problem because it has a thread that terminates immediately after establishing a connection.
Posted Date : 2006-02-02 09:54:45.0
--
Submitter has confirmed that fix addresses the issues that they observed.
Posted Date : 2006-02-24 08:38:30.0
|
|
Comments
|
Submitted On 12-APR-2006
donmadison
Is a fix for this available for JRE 1.5? We're getting VM crashes in production with SocketChannel.close() on the stack.
Submitted On 13-APR-2006
alan.bateman
The fix will also be in 5.0u8.
Submitted On 15-APR-2006
A simple workaround for this one is to call SocketChannel.read(ByteBuffer.allocate(0)) right after connecting the socket. That will reset the SocketChannelImpl.readerThread member so that no interrupting is done when the channel is closed.
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |