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.
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