JDK-8232114 : JVM crashed at imjpapi.dll in native code
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 8,11,14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-10-10
  • Updated: 2024-11-20
  • Resolved: 2020-08-26
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 11 JDK 15 JDK 16 JDK 8 Other
11.0.10-oracleFixed 15.0.2Fixed 16 b14Fixed 8u281Fixed openjdk8u282Fixed
Related Reports
Relates :  
JDK-8252470 - java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java fails on Windows
Relates :  
JDK-8262446 - DragAndDrop hangs on Windows
Description
JVM crashed at imjpapi.dll on Japanese OS which bundled with MS-IME.


# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffa2ac72aed, pid=584, tid=0x0000000000002d50
#
# JRE version: Java(TM) SE Runtime Environment (8.0_221-b27) (build1.8.0_221-b27)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.221-b27 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C  [imjpapi.dll+0x92aed]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
Comments
Sorry for the copyright year change, it was accidental. Note, with this change pushed to 8u-dev without JDK-8252470, drag-and-drop operations may hang in some cases.
30-10-2020
For 8u, this needed manual resolution of a copyright header in src/windows/native/sun/windows/awt_InputMethod.cpp. Normally, this should mean it goes through a cursory review. I'll push it on this occasion, but please ensure such patches are reviewed in future.
30-10-2020
removing the BPR ask --
23-10-2020
Thanks for the 8u approval, it needs to be pushed along with JDK-8252470, will wait for it.
08-10-2020
[~akasko] Please close the manual 8u backport bug, JDK-8252942, once you push. It will likely not close itself.
07-10-2020
Fix Request (11u): Backport to 11u requested because it is a part of 11.0.10-oracle. Patch applies cleanly. Testing (with JDK-8252470 included): jck:api/java_awt .
29-09-2020
Fix Request (15u): Backport to 15u requested because it fixes a potential crash problem. Patch applies cleanly. Testing (with JDK-8252470 included): jck:api/java_awt .
24-09-2020
It is not clear whether this fix needs to be brought to 15/13/11 first before proceeding with 8, please let me know if I need to do that or if someone is working on that.
23-09-2020
Fix Request (8u): Backport to 8u requested because it is a part of in 8u281-oracle. Patch depends on JDK-8132664 (not public, details: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-September/012731.html ) and applies cleanly on top of it after paths changes. 8u changeset with original attribution: https://cr.openjdk.java.net/~akasko/jdk8u/8232114/8232114_8u.patch
23-09-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/b5fb0d2a1687 User: psadhukhan Date: 2020-08-29 05:41:37 +0000
29-08-2020
URL: https://hg.openjdk.java.net/jdk/client/rev/b5fb0d2a1687 User: dmarkov Date: 2020-08-26 07:14:32 +0000
26-08-2020
The root cause of the crash is the lack of synchronisation in imjpapi.dll. In particular when IME messages are processed in the message loop and another message triggered through a SendMessage() call, this clears the buffer context so on further processing the message loop in IME context will point to invalid memory buffer. Microsoft article devoted to this issue: https://docs.microsoft.com/en-us/troubleshoot/windows/win32/ime-crash-processing-cross-thread-sent-message Possible fix: replace SendMessage() with PostMessage() for IME messages and implement event based mechanism to notify the sender that the message processing is completed.
11-08-2020
The problem is reproducible on jdk14, jdk11u and jdk8u
26-11-2019
According to the dump file the crash happens inside imjpapi.dll: IMJPAPI!TngAlloc+0x11 IMJPAPI!TngCreateG+0x5d IMJPAPI!TngCreateFromStr+0x20 IMJPAPI!FConvertIMLANGtoTANGOITEM+0x346 IMJPAPI!make_best+0x1e4 IMJPAPI!make_bunsetu+0x1d1 IMJPAPI!henkan_mi_henkan_moji+0x113 IMJPAPI!k_zen_henkan+0xe9 IMJPAPI!branch_henkan_kino+0x54 IMJPAPI!k_kanakanji+0xf7 IMJPAPI!IJConv::Control+0x2d742 IMJPAPI!IImeConvert::MakePhrasesFromControl+0x23c IMJPAPI!IImeConvert::ControlCnv+0x183 IMJPAPI!IImeConvert::NormalConvAll+0x12f IMJPAPI!IImeConvert::Control+0x3a59f IMJPAPI!CIImeIPoint::Control+0x71 IMJPAPI!CIConvertControl::ExecuteWithParam+0x10e IMJPAPI!CImeEMManager::ExecuteControl+0x135 IMJPAPI!CImeKeyEventHandler_JPN_Desktop_V1::DocumentFeed+0x25f32 IMJPAPI!CImeKeyEventHandler_JPN_Desktop_V1::ProcessKey+0xd4 IMJPAPI!CImeKeyEventHandler_JPN_Desktop_V1::OnKeyDown+0x125 IMETIP!CTipFnKeyEventHandler::OnKeyDown+0x11e IMETIP!CTipContextEditorMgr::_OnKeyboardEvent+0x24e IMETIP!Tsfutil::CTfKeyEventSink::OnKeyDown+0x35 msctf!CTip::OnKeyboardEvent+0xf0 msctf!CThreadInputMgr::_CallKeyEventSink+0x4d msctf!CThreadInputMgr::_KeyStroke+0x350b8 msctf!CThreadInputMgr::KeyDownUpEx+0x92 msctf!CicBridge::ToAsciiEx+0x15e msctf!ImeToAsciiEx+0x8f imm32!ImmTranslateMessage+0x21c user32!TranslateMessage+0x74 awt!Java_sun_awt_windows_WToolkit_getNumberOfButtonsImpl+0x261 awt!Java_sun_awt_windows_WToolkit_eventLoop+0x3b It looks like there is no any connections between the crash and AWT library.
26-11-2019