JDK-6186524 : Swing Basher throws an expection(EXCEPTION_ACCESS_VIOLATION) in windows XP professional
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version:
    jt4.1.1,1.3.1_04,1.4.2,5.0,5.0u1,5.0u3,5.0u6,6 jt4.1.1,1.3.1_04,1.4.2,5.0,5.0u1,5.0u3,5.0u6,6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS:
    generic,solaris,solaris_10,windows_2000,windows_2003,windows_xp generic,solaris,solaris_10,windows_2000,windows_2003,windows_xp
  • CPU: generic,x86
  • Submitted: 2004-10-29
  • Updated: 2011-01-20
  • Resolved: 2005-04-18
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.
Other JDK 6
5.0u10Fixed 6 b33Fixed
Related Reports
Duplicate :  
JDK-6573948 - DocPrintJob.print(Doc, PrintRequestAttributeSet) crashes JVM in certain conditions
Duplicate :  
JDK-4924298 - Prints some (complex) pages incompletely
Duplicate :  
JDK-6394247 - Random VM crashes while printing
Duplicate :  
JDK-6233707 - Reliability: SwingBasher crashes with OutMemoryError on sol10 AMD machine.
Duplicate :  
JDK-6213207 - SwingBasher throws OutOfMemoryError in windows 2003 machine.
Description
Bug Info:
---------
Runnning Swing Basher throws an expection(EXCEPTION_ACCESS_VIOLATION) in windows XP professional after 24th iteration.

SwingBasher PATH:
-----------------
/net/sqe.sfbay/global/nfs/ws1/1.5.0/swing/src/Swing_AllComponents/Automated/SwingBasher/tiger

JDK Version:
------------
java version "1.5.0_01-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-ea-b04)
Java HotSpot(TM) Client VM (build 1.5.0_01-ea-b04, mixed mode, sharing)

Steps to Reproduce:
-------------------
1.Set JAVA_HOME to tiger5.0_01 build 04
2.Set SB_TIMELIMIT 4320 (for 72 Hrs)
3. sh runint.sh

Addtional Info:
---------------
1. Swing Basher test was running 72 Hrs by using jdk1.5.0-rc-b63.But the same test has thrown an exception after 24th iteration by using jdk1.5.0_01 build 04.
2. For Verification check the below locations.

http://sqeweb.sfbay/st3/jdk1.5.0_01/ea/b04/Swing/SwingBasherWinXP_b63
http://sqeweb.sfbay/st3/jdk1.5.0_01/ea/b04/Swing/SwingBasherWinXP_U1

Please find the attached log file for finding more information about the bug.


---------------  S Y S T E M  D E T A I L S ---------------

OS: Windows XP Build 2600 Service Pack 2, v.2149

CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2, ht

Memory: 4k page, physical 261132k(11988k free), swap 634840k(408860k free)

vm_info: Java HotSpot(TM) Client VM (1.5.0_01-ea-b04) for windows-x86, built on Oct 12 2004 02:59:55 by "java_re" with MS VC++ 6.0
###@###.### 10/29/04 08:51 GMT
###@###.### 10/30/04 10:30 GMT
Comments
EVALUATION From the hotspot error log at: http://sqeweb/st3/jdk1.5.0_01/ea/b04/Swing/SwingBasherWinXP_U1/results/hs_err_pid2824.log the problem appears to be in native printing code. ###@###.### 10/29/04 23:59 GMT ================ Nothing has changed in any code remotely in this area in _01 so either its not particularly reproducible or something else changed to provoke it. The JTable printing test presumably hasn't been in the SwingBasher for long so seeing how reproducible it is would be worthwhile. Looking at the Java stack trace: Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J sun.awt.windows.WPrinterJob.setLogicalFont(Ljava/awt/Font;IF)Z J sun.awt.windows.WPathGraphics.drawString(Ljava/lang/String;FFLjava/awt/Font;Ljava/awt/font/FontRenderContext;F)V The native method its crashing in appears to be sun.awt.windows.WPrinterJob.setLogicalFont and that goes 3 or 4 more calls deep in awt.dll before crashing C [ntdll.dll+0x58eb] C [MSVCRT.dll+0x1c3c9] C [MSVCRT.dll+0x1c3e7] C [MSVCRT.dll+0x1c42e] C [awt.dll+0xee667] C [awt.dll+0xee6ed] C [awt.dll+0xce109] C [awt.dll+0xdbdca] The only call in setLogicalFont of any note is : AwtFont::GetFont(env, font, rotation, awScale); So this crashes somewhere in createing an AWT native font object. It doesn't appear to be a call into GDI however, probably some kind of memory allocation routine instead?? So its difficult to say what the true cause of the problem is from this information ###@###.### 10/30/04 00:53 GMT This bug is not new, its in fact relatively old. I reproduced it on JDK 1.5 beta 1. You can't go back much further than that using this test case since the JTable printing API is new in 1.5. So its curious why this is only being seen now. The exact crash seen in the original bug report is not the normal failure. Its almost always an OutOfMemoryError. It doesn't happen at a predictable time. Anything from 2 to 100 or more full loops of the test program. It looks a lot like the finalizer thread is for some reason starved and GC can't free these resources, so throws OutOfMemoryError. So this looks to be another case of "finalizers are evil". But its not at all clear why the finalizer thread gets into this predicament so unpredictably. Lowering the priority of the finalizer thread does hasten this problem, but by default its at priority 8, so should get a fair amount of CPU. That's higher than the app threads that create the garbage. There are 2 principal sets of objects that are needing finalisation here. 1) The Graphics2D subclass that is used in the printing implementation. java.awt.Graphics has a finalizer which dispose()'s of native resources. For many releases the SunGraphics2D class has overridden this to be empty, allowing for more prompt GC. [It doesn't need one and a different mechanism is used to dispose any native resources that may be held rather than assuming all instances hold such resources]. The same can and should be done for the printer graphics classes. The finalize() method in these classes has the inherited behaviour of calling dispose(). The dispose() method for these classes calls the dispose() method of a delegate G2D object, which is always a SunGraphics2D. Promptly calling dispose() on these objects is helpful in freeing resources, but leaving it to finalisation is not the answer here. In fact its probably delaying freeing these resources. There are also already some "prompt" calls to dispose() so the finaliser is probably duplicating those. The simple fix is to add an empty finalize() method and let all these objects be GC'd without finalisation. 2) The java.awt.Font class has a finalizer to clean up the native data structures allocated by AWT. These font objects are also larger than one might like because of the way they are being created. Swing/JTable is indirectly using Font.deriveFont which in 1.5 (and prior releases) always creates an internal Hashtable into which it inserts several attributes, including an AffineTransform. So failing to collect the Font also leaves around Hashtables, Entry objects and AffineTransforms. JDK 1.6 already has fixed the unnecessary creation of the Hashtable etc, so that can reduce memory usage. But this only puts off the still inevitable issue with Font finalisation. Why so many Font objects anyway? The main reason appears to be that that Swing create()'s lots of new Graphics and this defeats the printing implementation's attempt to remember the last font used on the Graphics. Printing needs to "derive" a new Font at a size suitable for printing. Profiling shows that this still does help greatly - reducing the number of fonts that would otherwise be created by around 40%. Possibilities for fixes in the library code include - reduce the number of Font objects being created, alleviating the strain on the finalizer, eg cache Font objects some place they can be accessed independently of the Graphics, eg on the WPrinterJob. - use a mechanism other than finalization to remove these objects. On windows what the finalizer does is "post" a message to delete the C++ AwtObject. As noted in the Graphics case the finalization happens even if there isn't an object to free. So this is tempting because in the majority of apps now the "peer" isn't used. ie its mainly for AWT components, its not applicable to Swing components. The printing code uses some AWT implementation for GDI access to logical fonts, which is why its being seen here in the context of a "Swing" app. The first of these can be viewed as appropriate since the problem of creating many Font objects isn't at all common, and there's reason to believe we could reduce the number of Font objects created to a few dozen from thousands. The second is attractive because it fixes the problem for other such cases even if we don't have examples of it. Since this is neither a new nor serious problem I don't think this needs to be fixed in an update release, it can be committed to mustang. Note because this was subsequently discovered to be the fix for 4924298, 6394247 and 6308772 it is being backported to a 5.0 update release too. ** This fix has been backported to JDK1.5 update 10. ###@###.### 2004-11-15 20:39:03 GMT
29-10-2004