This is a spinoff from [1]. The original issue and the patch originally proposed (see [2]) were too unwieldy, so I decided to split it up in multiple patches. This is the first patch.
Functions from dbghelp.dll are not threadsafe; calls to them must be synchronized. But dbghelp.dll can be used by the two live WindowsDecoder objects in parallel from different threads. In addition to that, dbghelp.dll functions are used from other places within os_windows.cpp, when writing minidumps.
So, dbghelp.dll may get loaded and used from different independent places in the VM, which do not synchronize access. Apart from that, it is a lot of code redundancy.
Proposed fix: Centralize dbghelp handling into a singleton.
[1] https://bugs.openjdk.java.net/browse/JDK-8185712
[2] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-August/024286.html
Functions from dbghelp.dll are not threadsafe; calls to them must be synchronized. But dbghelp.dll can be used by the two live WindowsDecoder objects in parallel from different threads. In addition to that, dbghelp.dll functions are used from other places within os_windows.cpp, when writing minidumps.
So, dbghelp.dll may get loaded and used from different independent places in the VM, which do not synchronize access. Apart from that, it is a lot of code redundancy.
Proposed fix: Centralize dbghelp handling into a singleton.
[1] https://bugs.openjdk.java.net/browse/JDK-8185712
[2] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-August/024286.html
- relates to
-
JDK-8185706 [windows] Native callstacks printing terminates prematurely
-
- Resolved
-
-
JDK-8311609 [windows] Native stack printing lacks source information for dynamically loaded dlls
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-