JDK-6723941 : Crash in sun.awt.windows.WToolkit.eventLoop()
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6u10,6u13
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_vista
  • CPU: x86
  • Submitted: 2008-07-09
  • Updated: 2011-01-19
  • Resolved: 2009-05-15
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 6 JDK 7
6u14 b01Fixed 7Fixed
Related Reports
Relates :  
Relates :  
Description
Bugster crashes with jfk6u10b26, b27 (didn't ry other builds):
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x8c00ecd4, pid=11340, tid=11944
#
# Java VM: Java HotSpot(TM) Client VM (11.0-b14 mixed mode, sharing windows-x86)
# Problematic frame:
# C  0x8c00ecd4
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  T H R E A D  ---------------

Current thread (0x01462800):  JavaThread "AWT-Windows" daemon [_thread_in_native, id=11944, stack(0x03cb0000,0x03d00000)]

siginfo: ExceptionCode=0xc0000005, reading address 0x8c00ecd4

Registers:
EAX=0x00000002, EBX=0x770c7ac1, ECX=0x00000000, EDX=0x03cfe6bc
ESP=0x03cfe690, EBP=0x03cfe6e8, ESI=0x00221bd8, EDI=0x00000000
EIP=0x8c00ecd4, EFLAGS=0x00010246

Top of Stack: (sp=0x03cfe690)
0x03cfe690:   75e2fcd6 0025053c 0000003d 000009cc
0x03cfe6a0:   00000000 00000002 00000003 3d1a936b
0x03cfe6b0:   00000000 00221bd8 770c7ac1 8c00ecd4
0x03cfe6c0:   00000002 00000003 770c7ac1 03cff088
0x03cfe6d0:   03cfe6ac 03cfe28c 03cfe774 75ed9521
0x03cfe6e0:   4b37897b 00000000 03cfe70c 75e2fc8b
0x03cfe6f0:   00000002 0025053c 0000003d 000009cc
0x03cfe700:   00000000 04227930 0000003d 000009cc 

Instructions: (pc=0x8c00ecd4)
0x8c00ecc4:   
[error occurred during error reporting (printing registers, top of stack, instructions near pc), id 0xc0000005]

Stack: [0x03cb0000,0x03d00000],  sp=0x03cfe690,  free space=313k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x8c00ecd4
C  [comctl32.dll+0x6fc8b]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  sun.awt.windows.WToolkit.eventLoop()V+0
j  sun.awt.windows.WToolkit.run()V+69
j  java.lang.Thread.run()V+11
v  ~StubRoutines::call_stub

---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x0487d000 JavaThread "TimerQueue" daemon [_thread_blocked, id=11220, stack(0x07280000,0x072d0000)]
  0x04880400 JavaThread "AWT-EventQueue-0" [_thread_blocked, id=11468, stack(0x077a0000,0x077f0000)]
  0x0487e400 JavaThread "AWT-Shutdown" [_thread_blocked, id=11408, stack(0x07220000,0x07270000)]
  0x04880c00 JavaThread "D3D Screen Updater" daemon [_thread_blocked, id=11480, stack(0x06b90000,0x06be0000)]
  0x0487cc00 JavaThread "TimerQueue" daemon [_thread_blocked, id=11512, stack(0x078f0000,0x07940000)]
  0x01479000 JavaThread "CacheCleanUpThread" daemon [_thread_blocked, id=12100, stack(0x03fd0000,0x04020000)]
  0x0146f800 JavaThread "CacheMemoryCleanUpThread" [_thread_blocked, id=10520, stack(0x03f80000,0x03fd0000)]
  0x0146c400 JavaThread "traceMsgQueueThread" daemon [_thread_blocked, id=11532, stack(0x03eb0000,0x03f00000)]
  0x003e9c00 JavaThread "DestroyJavaVM" [_thread_blocked, id=11356, stack(0x007b0000,0x00800000)]
  0x01465400 JavaThread "Javaws Secure Thread" [_thread_blocked, id=10848, stack(0x03d00000,0x03d50000)]
=>0x01462800 JavaThread "AWT-Windows" daemon [_thread_in_native, id=11944, stack(0x03cb0000,0x03d00000)]
  0x01436800 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=12044, stack(0x036c0000,0x03710000)]
  0x01418800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=11364, stack(0x03620000,0x03670000)]
  0x01414000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=10708, stack(0x035d0000,0x03620000)]
  0x01413800 JavaThread "Attach Listener" daemon [_thread_blocked, id=11652, stack(0x03580000,0x035d0000)]
  0x01409000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=10600, stack(0x03530000,0x03580000)]
  0x013c5000 JavaThread "Finalizer" daemon [_thread_blocked, id=12024, stack(0x034e0000,0x03530000)]
  0x013c3c00 JavaThread "Reference Handler" daemon [_thread_blocked, id=10324, stack(0x03490000,0x034e0000)]

Other Threads:
  0x013c2400 VMThread [stack: 0x01300000,0x01350000] [id=10756]
  0x01419800 WatcherThread [stack: 0x03670000,0x036c0000] [id=12264]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

ap
 def new generation   total 1088K, used 517K [0x24020000, 0x24140000, 0x24500000)
  eden space 1024K,  44% used [0x24020000, 0x240915c8, 0x24120000)
  from space 64K, 100% used [0x24130000, 0x24140000, 0x24140000)
  to   space 64K,   0% used [0x24120000, 0x24120000, 0x24130000)
 tenured generation   total 13356K, used 8357K [0x24500000, 0x2520b000, 0x28020000)
   the space 13356K,  62% used [0x24500000, 0x24d29698, 0x24d29800, 0x2520b000)
 compacting perm gen  total 12288K, used 9363K [0x28020000, 0x28c20000, 0x2c020000)
   the space 12288K,  76% used [0x28020000, 0x28944fd8, 0x28945000, 0x28c20000)
    ro space 8192K,  63% used [0x2c020000, 0x2c533888, 0x2c533a00, 0x2c820000)
    rw space 12288K,  53% used [0x2c820000, 0x2ce87c08, 0x2ce87e00, 0x2d420000)


See full hs_err file attached

Comments
EVALUATION While there was a fix for this bug, its application led to 6830549. After finding out why, I approached AWT with the problem. They informed me that these issues have already been resolved in 5u14 as part of the "big awt fix" and that backporting this to 1.4.2 would require considerable effort and engineering resources. I informed QA and received the response below. Based on that I'm closing as "will not fix" QA's response: "In summary, these issues cannot be fixed unless we backport the "big AWT fix" from 5u14. Obviously this would take a massive engineering effort. However, given the complexity and your assessment on engineering effort involved and no customer asking for it, I think, fine to close 6723941 as 'Will Not Fix' with your analysis and comments so that we know why this bug is closed if some one asks in the future."
22-04-2009

SUGGESTED FIX http://sa.sfbay.sun.com/projects/awt_data/6u14/6723941/
21-01-2009

EVALUATION the submitter confirmed that the bugster doesn't fail using a build with the fix.
21-01-2009

SUGGESTED FIX ------- awt_Frame.cpp ------- *** /tmp/sccs.hZvNlM 2009-01-20 16:58:34.000000000 +0300 --- awt_Frame.cpp 2009-01-20 16:58:38.000000000 +0300 *************** *** 298,304 **** AwtComponent::GetComponentImpl(::GetParent(hwnd)); if (!parent || parent->GetProxyFocusOwner() != hwnd || ! message == AwtComponent::WmAwtIsComponent) { return ComCtl32Util::GetInstance().DefWindowProc(NULL, hwnd, message, wParam, lParam); } --- 298,305 ---- AwtComponent::GetComponentImpl(::GetParent(hwnd)); if (!parent || parent->GetProxyFocusOwner() != hwnd || ! message == AwtComponent::WmAwtIsComponent || ! message == WM_GETOBJECT) { return ComCtl32Util::GetInstance().DefWindowProc(NULL, hwnd, message, wParam, lParam); }
20-01-2009

EVALUATION It's likely that the issue related to Vista accessibility features. Based on our investigations, the last native message coming from the native system to AWT is the WM_GETOBJECT message. MSDN for WM_GETOBJECT says: "Active Accessibility sends the WM_GETOBJECT message to obtain information about an accessible object contained in a server application". The problem might appear when AWT creates a proxy focus owner (the proxy window is a WS_CHILD window and is a part of current AWT focus subsystem). AWT sets custom window procedure on the focus proxy owner (the proxy is the native focus owner). Later, all native key messages coming to the proxy window procedure and the procedure generates appropriate Java event. It looks wrong that the window procedure handles WM_GETOBJECT messages (just because the messages are coming to the procedure as well); the "suggested fix" section includes a changes in ProxyWindowProc to ignore all WM_GETOBJECT messages. For some reason, the issue isn't reproducable on my local Windows Vista machine, it's very strange. I enabled one of the accessibility features and WM_GETOBJECT messages are coming to AWT objects now but crash doesn't happens.
20-01-2009

EVALUATION The stack trace is very close to 6542975.
16-07-2008

EVALUATION I tired to run the test case attached to 6542975. The test crashes starting from jdk7-b02 (as described in 6542975's comments) but doesn't crash with jdk6u10 (tried b27,b26,b25).
16-07-2008

EVALUATION The stack trace looks similar to 6542975, however the test for 6542975 doesn't crash with 6u10-b24 or 6u10-b27.
10-07-2008