JDK-7034299 : Faulty Winsock initialization code in src/os/windows/vm/os_windows.cpp
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2011-04-06
  • Updated: 2017-08-04
  • Resolved: 2013-04-12
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.
JDK 7 JDK 8 Other
7u171Fixed 8Fixed hs24Resolved
Related Reports
Duplicate :  
JDK-8010190 - os_windows missing winsock initialization on some paths
Description
Dan discovered a faulty Winsock initialization code in src/os/windows/vm/os_windows.cpp:initSock().

Copied from Dan's email, the line number may not be accurate.
       This block is supposed to only allow one thread to init the
       WinSock2 stuff. Consider this scenario:

       - thread-1 makes it through line 4638 so it owns the mutex
       - thread-2 makes it past line 4635 so it calls mutexInit()
         on the mutex that thread-1 owns; does this mess up the
         mutex?
       - thread-1 finishes initializing WinSock2 and gets to line 4647
         where it calls mutexUnlock() on the mutex; does this work when
         thread-2 has called mutexInit() on the mutex?
Comments
Will not fix in 7/hsx24. Already fixed in 8/hs25.
12-04-2013
So based on 8010190 it seems this code is now a lot more active than it used to be. So P4 is probably not reasonable any more.
20-03-2013
PUBLIC COMMENTS The synchronization initialization problem is easily fixed by moving the ::mutexInit into os::init() or os::init2(). There is still a potential visibility issue if a second thread can see sock_initialized, but doesn't see the affects of WSAStartup - but an OrderAccess::fence() before setting sock_initialized to true would fix that. The bigger problem with this code is the failure semantics - this code has no idea how to handle failure. It marks initialization as complete regardless, and proceeds to call get_host_by_name regardless. That said as far as I can see there is only one client of this code: networkStream::connect(); and as far as I can see there is only one client of that code: IdealGraphPrinter - and that is only available in a non-product build! So to me fixing this is not that important right now - but conversely give its limited use, a simple fatal_error to abort the VM might be the best way to handle failure here.
06-04-2011