United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6536107 GDI leak detected by opening the Print Dialog repeatedly
JDK-6536107 : GDI leak detected by opening the Print Dialog repeatedly

Details
Type:
Bug
Submit Date:
2007-03-19
Status:
Resolved
Updated Date:
2011-02-16
Project Name:
JDK
Resolved Date:
2008-07-24
Component:
deploy
OS:
windows_xp
Sub-Component:
plugin
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
5.0u12
Fixed Versions:
5.0u17 (b02)

Related Reports
Backport:
Backport:
Relates:
Relates:
Relates:

Sub Tasks

Description
The test case and the procedure attached to the bug report. Open Task Manager to detect GDI leak.

1) Invoke the attached TestApplet/PrintApplet.html by double-clicking.
You will see an applet with the button "Print".
2) Click the "Print" button. You will see a print confirmation dialogue.
3) Click the "Yes" button, then "Page Setup" dialogue will open.
4) Click the "OK" or "Cancel" button, then "Print" dialogue will open.
5) Click the "Cancel" button.
6) Repeat step 2) to 5).

GDI counts reached to around 5000 for about 2 hours.

                                    

Comments
EVALUATION

I do see the GDI count growing up for every iteration of steps 2 to 5 as dsecribed in the description section.

I see multiple reasons for the leak:

-  DummyDialog gets created for every invocation of PrinterJob.getPrinterJob call (and perhaps for page dialog also) resulting in two objects staying in memory for every iteration of the print button click.  We seem to be hiding the dummydialog instead of disposing it when we are done with it. And we create a new instance of dummydialog every time the print permission check is done.
-  The pageDialog and printDialog objects don't get destroyed either and hence their native handle remains in memory.

The leaks are even worse if the print button code is run using a standalone. The reason behind it is that we create a new Frame and assign it as the parent of the page/print dialog thereby leaking further.  In the case of plugin, we assign the active embedded frame as the parent of page/print dialog.
                                     
2007-04-26
EVALUATION

The fix involves closing the print dialog handles appropriately in both j2se and deploy code after the dialog has been disposed.  For j2se, it has already been fixed and integrated alongwith the fix for bug 6530198 in 5.0u14. On deploy, it's a simple fix of disposing the dummy dialog which is created for providing permissions to print through plugin.
                                     
2007-11-30
EVALUATION

sync from 5.0u16-rev-b06
                                     
2008-10-23



Hardware and Software, Engineered to Work Together