Hello Matthias, Thank you for your contribution. I have a question to the fix.
Since you are suggesting to switch from STA to MTA which consequences will it have to the current JDK code that was written to support STA only?
--Semyon On 02/08/2018 10:32 AM, Matthias Bläsing wrote:
Hi all, last month I saw the message from Reinhard Pointer on this list: http://mail.openjdk.java.net/pipermail/swing-dev/2018-January/008132.html referring to this bug: https://bugs.openjdk.java.net/browse/JDK-8189938 With the instructions given in: https://bugs.openjdk.java.net/browse/JDK-8193928 (closed as duplicate of JDK-8189938) I was able to reproduce the problem on a clean Windows 10 Installation, as described in the initial report. The resulting exception leads to my proposed fix: Could not initialize COM: HRESULT=0x80010106 That HRESULT translates to: RPC_E_CHANGED_MODE This means, that the COM subsystem is already initialized, but with a different mode. The code uses CoInitialize and this initializes the threading module to be apartment threaded. The above HRESULT means the thread was already initialized to be multi-threaded. The mode can't be changed after is was set once, so instead of bailing out, I suggest to accept the situation and initialize to be multi- threaded. The consequence is that calls from COM to Java could end up on the wrong thread. A quick look through the code suggest, that COM advises are not used, so this is a risk that should be taken. The fix in this case works like this: * try to initialize COM as it was * check the return * if it is RPC_E_CHANGED_MODE, retry initialization als multi-threaded * only if that fails raise an exception One could argue, that if COM is already initialized, you don't need to do it yourself, but documentation states, that every successful call to CoInitialize/CoInitializeEx must be paired with CoUninitialize. D3DPipelineManager tracks this in bComInitialized, the other two callers in the JDK are: - PLATFORM_API_WinOS_DirectSound.cpp - ShellFolder2.cpp Both are covered in the patches. For ShellFolder2 there is an initialization check, this is modified as described above. And if both initialization variant (apartment threaded and multi threaded fail) this raises an exception. PLATFORM_API_WinOS_DirectSound is slightly different. The fallback in the initialization is still done, but no exception is raised in the error case. This follows the code flow before this change. I attached the diffs against JDK10 and JDK9 to this email. If they are stripped, they can be found here: http://www.doppel-helix.eu/JDK8189938-openjdk9.diff http://www.doppel-helix.eu/JDK8189938-openjdk10.diff I hope this helps with a fix. Greetings Matthias
