JDK-6536107 : GDI leak detected by opening the Print Dialog repeatedly
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 5.0u12
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-03-19
  • Updated: 2011-02-16
  • Resolved: 2008-07-24
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 Other JDK 6
5.0u16-revFixed 5.0u17 b02Fixed 6-poolResolved
Related Reports
Relates :  
JDK-6589458 - Some memory leaks/allocation conflicts in printing and fonts code, Win32
Relates :  
JDK-6505072 - Memmory,Handles and GDI Objects leaks while loading ArcTest Demo.
Relates :  
JDK-6634684 - GDI leaks in 6536107 should be resolved
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 sync from 5.0u16-rev-b06
23-10-2008
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.
30-11-2007
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.
26-04-2007