JDK-6353972 : REGRESSION: GUI fails to paint text with large heap size setting
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.2,5.0,5.0u2,5.0u12,5.0u6,6u1
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_nt,windows_xp
  • CPU: x86
  • Submitted: 2005-11-22
  • Updated: 2010-12-03
  • Resolved: 2006-04-19
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.0u12Fixed 6 b81Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)

Also tested on:
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

EXTRA RELEVANT SYSTEM CONFIGURATION :
HyperThreaded Intel Processor, 2 GB of system memory

A DESCRIPTION OF THE PROBLEM :
Swing fails to paint _ALL_ of the text on any GUI if it is started with a large heap size.

For example, on my pc - '-Xmx1050M' works ok.
However, the same application launched with '-Xmx1100M' fails.



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run my provided class (without setting any heap size parameters)

(alternatively - use any java swing application)



Now run the class again with your heap size set very high - for example - '-Xmx1100M'

Note that all text in the GUI fails to paint.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The GUI should behave the same no matter what the max heap size is set to.
ACTUAL -
No text appears in any Swing component.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
package bugs;

import java.awt.BorderLayout;
import java.awt.Dimension;
import java.awt.event.ActionEvent;

import javax.swing.JButton;
import javax.swing.JComboBox;
import javax.swing.JFrame;

public class BugJavaGui extends JFrame{

	public BugJavaGui()
	{
		final JComboBox jComboBox = new JComboBox();
		jComboBox.setEditable(true);
		jComboBox.addItem("item 1");
		jComboBox.addItem("item 2");
		jComboBox.addActionListener(new java.awt.event.ActionListener() {
			public void actionPerformed(ActionEvent e) {
				System.out.println("Selected Item Changed");
				System.out.println(jComboBox.getSelectedIndex());
				System.out.println();
			}
		});

		JButton jButton = new JButton();
		jButton.setText("click me");
		jButton.addActionListener(new java.awt.event.ActionListener() {
			public void actionPerformed(ActionEvent e) {
				System.out.println("Button was clicked");
				System.out.println(jComboBox.getSelectedItem());
			}
		});
		this.getContentPane().add(jComboBox, BorderLayout.NORTH);
		this.getContentPane().add(jButton, BorderLayout.SOUTH);

		this.setSize(new Dimension(200, 200));
		this.setVisible(true);
	}

	public static void main(String[] args) throws Exception
	{
		BugJavaGui bug = new BugJavaGui();
	}
}
---------- END SOURCE ----------

Release Regression From : 1.4.2
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

Comments
EVALUATION Some other fixes that went into mustang allow simple workarounds for this problem. We detect and error and disable the use of DirectDraw acceleration for the surface which caused errors.
07-04-2006

EVALUATION I found out that this stopped working somewhere between 5.0beta1 (1.5.0-beta-b32d) and 5.0beta2 (1.5.0-beta2-b51). But when I copied the VM from beta2 into beta1 jre, the problem reproduced with beta1 jre. So something in hotspot's memory mapping management changed between beta1 and beta2 which caused this problem. Using binary division, I found that it was broken in beta2 build b45. That is, a beta1 jre with b45 vm fails, while it works fine with b44 vm. Most likely, the following fix in b45 hotspot putback is responsible: 5017808: Memory allocation order change causes DLLs to load out of place
17-03-2006

EVALUATION I can reproduce the bug on my notebook (Intel 855 video, 496M of ram, winxp pro) with heap set to 1500m. Apparently ddraw.dll doesn't like to be loaded into high addresses. I've found the following old article on msdn: http://support.microsoft.com/?id=257655 From the article: "Ddraw needs access to a certain virtual memory address to use as a global heap space. If this address is already occupied , Ddraw.dll does not load and the following error message occurs:" The article is only applied to DirectX 3, so looks like they've addressed some issues and it now doesn't fail outright, that is, LoadLibrary("ddraw.dll") succeeds. In our case, it's the Lock of offscreen ddraw surfaces that fails (that's why the text is messed up) - it fails with DDERR_GENERIC. Also, I see occasional DDERR_CANTCREATEDC errors. Unfortunately we don't have a backup mechanism for locking offscreen surfaces as we do with on-screen (there if the ddraw lock fails we use GDI DIB sections), so if we fail to lock the offscreen surface we just no-op, no error is propagated. Since the LoadLibrary doesn't fail, I think it'd be hard to detect this particular problem - looks like the conditions under which the failure occurs varies from configuration to configuration. I have another system with 1.5G of ram, and there we work just fine with 1500m of heap. At this point the only wasy to fix this that I see is to beef up our error handling so we at least have a backup for DDLock failure in offscreen case. It'd be nice if we could just disable ddraw for cases like these. Also, I'll need to find out why it worked in 1.4.2.
20-12-2005

WORK AROUND disable the use of ddraw by either passing -Dsun.java2d.noddraw=true as command line argument, or by setting _JAVA_OPTIONS=-Dsun.java2d.noddraw=true .
20-12-2005

EVALUATION There's an MS FAQ that's relevant here : http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c_dec_2004/directx/GamesForWindows/TopIssues.asp
07-12-2005

EVALUATION I'm not sure what 2d can do in this case. We have a certain amount of memory that we do need to be using, for different hw acceleration cases. We can look at if this amount seems excessive, but the correct solution is to not set a max heap size and have the VM use ergonomics settings to figure out the right heap size.
01-12-2005

EVALUATION Based on Dmitri's comments I'm reassigning to 2D.
01-12-2005