This topic describes how to determine if a crash is related to AWT, as well as how to troubleshoot such crashes.
To distinguish an AWT crash:
When a crash occurs, an error log is created with information and the state obtained at the time of the crash. For detailed information about the fatal error log file, see Appendix A.
A line near the top of the file indicates the library where the error occurred. Example 10-3 shows a part of the error log file in the case when the crash was related to the AWT library.
Example 10-3 Error Log for AWT Library Crash
... # Java VM: Java HotSpot(TM) Client VM (1.6.0-beta2-b76 mixed mode, sharing) # Problematic frame: # C [awt.dll+0x123456] ...
However, the crash can happen somewhere deep in the system libraries, although still caused by AWT. In such cases the indication awt.dll does not appear as a problematic frame, and you need to look further in the file, in the section Stack: Native frames: Java frames as shown in Example 10-4.
Example 10-4 Error Log for Stack Native Frames
Stack: [0x0aeb0000,0x0aef0000), sp=0x0aeefa44, free space=254k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x00abc751 C [USER32.dll+0x3a5f] C [USER32.dll+0x3b2e] C [USER32.dll+0x5874] C [USER32.dll+0x58a4] C [ntdll.dll+0x108f] C [USER32.dll+0x5e7e] C [awt.dll+0xec889] C [awt.dll+0xf877d] 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 V [jvm.dll+0x83c86] V [jvm.dll+0xd870f] V [jvm.dll+0x83b48] V [jvm.dll+0x838a5] V [jvm.dll+0x9ebc8] V [jvm.dll+0x108ba1] V [jvm.dll+0x108b6f] C [MSVCRT.dll+0x27fb8] C [kernel32.dll+0x202ed] 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
If the text awt.dll appears somewhere in the native frames, then the crash might be related to AWT.
To troubleshoot an AWT crash:
Most of the AWT crashes occur on the Windows platform and are caused by thread races. Many of these problems were fixed in Java SE 6, so if your crash occurred in an earlier release, first try to determine if the problem is already fixed in the latest release.
One of the possible causes of crashes is that many AWT operations are asynchronous. For example, if you show a frame with a call to frame.setVisible(true), then you cannot be sure that it will be the active window after the return from this call.
Another example concerns native file dialogs. It takes some time for the operating system to initialize and show these dialogs, and if you dispose of them immediately after the call to setVisible(true), then a crash might occur. Therefore, if your application contains some AWT calls running simultaneously or immediately one after another, it is a good idea to insert some delays between them or add some synchronization.
