JDK-2127411 : JDK windows printing implementation leaks GDI objects.
  • Type: Backport
  • Backport of: JDK-6255588
  • Component: client-libs
  • Sub-Component: 2d
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2005-06-16
  • Updated: 2008-02-06
  • Resolved: 2005-09-16
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.0u5 b04Fixed 6Fixed
Comments
EVALUATION I noticed this growth when fixing 6186524 but wasn't able to track down the cause until now. Handles to a printer DC, DEVNAMES, and DEVMODE are stored in the WPrinterJob object. These are retrieved in several places in native code. Some of these do not use DEVMODE but do retrieve the DC and DEVNAMES. If they are null then the call PrintDlg() to get values. validatePaper() correctly notes its a "privateDC" but getDefaultPage() does not and that is the problem. Every defaultPage() call that is made before the fields are set in the PrinterJob gets its own DC and DEVNAMES and leaks its - having forgot that it allocated them itself. Yuck. Not all code paths are bound to trigger this as some may cause these fields to be filled in before these fns are called, or they may not be called at all. But it appears that many programs will trigger it. The offending implementation of defaultPage() is called when an app calls setPrintable(Printable) which is almost universal. ie the extremely common two line pattern of PrinterJob printerJob = PrinterJob.getPrinterJob(); printerJob.setPrintable(myPrintable); will cause a leak. This seems reproducible from 1.4.0 (merlin) onwards. It looks as if it was introduced by the fix to 4545985:Printerjob.defaultPage returns incorrect default page size That fix also added a comment that it was expecting these to be already initialised. Perhaps it was expected that user code could not reach this function without a printer being initialised. That may have been true then perhaps?? Also it looks like this was reported once before 4737016:PrinterJob.defaultPage() does not free resources in Windows and the fix for that in 1.4.2 was not complete ?? ###@###.### 2005-04-14 21:41:42 GMT The same submitter observed that the workaround didn't cure all leaks. The problem there was that whatever non-stock HPEN, HBRUSH or HFONT was selected into the printDC at the time the job ended was not explicitly deleted. This could cause up to 3 additional GDI Objects per job. This fixes that. I also found that the recent refresh printers work caused some new handle leaks as it can start multiple notification threads. This will quickly fix that too. ###@###.### 2005-07-19 18:07:49 GMT
19-07-2005