JDK-8047334 : Reapply fix for "8032901 WaitForMultipleObjects() return value not handled appropriately"
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows
  • Submitted: 2014-06-19
  • Updated: 2017-05-30
  • Resolved: 2017-05-30
Related Reports
Duplicate :  
JDK-6254918 - WaitForMultipleObjects() return value not handled appropriately
Relates :  
JDK-8032901 - WaitForMultipleObjects() return value not handled appropriately
Relates :  
JDK-8046024 - JDI shared memory transport failed with "Observed abandoned IP mutex"
Description
The fix for JDK-8032901 cause a lot of failures in testing (JDK-8046024) and was backed out.

The fix may still be a good fix, but in that case it needs to be accompanied by changes to the code so that we do not abandon mutexes.
Comments
This is not on our list of current priorities. If this changes please re-open this issue. Closing as WNF.
30-05-2017
From the original bug report the issue is that with the WAIT_ABANDONED case we would return SYS_ERR but would in fact have locked the mutex. The calling code is: /* enter the stream's mutex and (optionally) check for a closed stream */ static jint enterMutex(Stream *stream, sys_event_t event) { jint ret = sysIPMutexEnter(stream->mutex, event); if (ret != SYS_OK) { if (IS_STATE_CLOSED(stream->state)) { setLastErrorMsg("stream closed"); } return ret; } if (IS_STATE_CLOSED(stream->state)) { setLastErrorMsg("stream closed"); (void)leaveMutex(stream); return SYS_ERR; } return SYS_OK; } Leaving the mutex locked was considered a "Bad Thing". The original proposed fix simply ignored the fact the mutex had been abandoned and return SYS_OK because we have the mutex. However I argued that encountering an abandoned mutex was a serious error that should be reported and trigger an abort (as we do for all serious errors). I have yet to see any analysis of the failed tests that show how/why we encounter the abandoned mutex.
22-07-2014
Seeing a return value of WAIT_ABANDONED from WaitForMultipleObjects() is definitely an issue that needs to be investigated. I think there are two main questions that need to be answered: 1) what specific sequence of operations is causing WAIT_ABANDONED to be returned? 2) what does the pre-JDK-8032901 do when WAIT_ABANDONED is returned? Here is code block before the fix for JDK-8032901 was applied: src/windows/transport/shmem/shmem_md.c 192 int 193 sysIPMutexEnter(sys_ipmutex_t mutex, sys_event_t event) 194 { 195 HANDLE handles[2] = { mutex, event }; 196 int count = event == NULL ? 1 : 2; 197 DWORD rc; 198 199 sysAssert(mutex); 200 rc = WaitForMultipleObjects(count, handles, 201 FALSE, /* wait for either, not both */ 202 INFINITE); /* infinite timeout */ 203 return (rc == WAIT_OBJECT_0) ? SYS_OK : SYS_ERR; 204 } My interpretation of line 203 is that if WAIT_ABANDONED is returned in the 'rc' variable, then sysIPMutexEnter() returns SYS_ERR. What happens to the calling code when SYS_ERR is returned by sysIPMutexEnter()? And why was that code considered insufficient? I don't see any such analysis in the original bug report (JDK-8032901).
10-07-2014