JDK-6445576 : Exceptions thrown when creating diff print jobs on different threads multiple times, WinXP
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-06-30
  • Updated: 2010-04-02
  • Resolved: 2007-07-27
Related Reports
Duplicate :  
Relates :  
Description
I have an infinite loop within which I am creating 3 threads for each iteration. In thread 1, I am creating a PrintJob and calling some methods on print job and disposing it, without actually printing anything. In thread2, I am doing the same for PrinterJob and in thread 3, I am doing for DocPrintJob. 

This test is executed indefinitely and nothing is actually printed. However, all the print jobs are using the same printer. After some loops, I am seeing lot of different exceptions being thrown by Toolkit.getPrintJob(). Here are the stack traces:

java.lang.NullPointerException
at sun.print.Win32PrintService.initMedia(Win32PrintService.java:303)
at sun.print.Win32PrintService.getSupportedAttributeValues(Win32PrintService.java:1139)
at sun.print.RasterPrinterJob.updatePageAttributes(RasterPrinterJob.java:519)
at sun.print.RasterPrinterJob.setPrintable(RasterPrinterJob.java:965)
at sun.print.PrintJob2D.printDialog(PrintJob2D.java:475)
at sun.awt.windows.WToolkit.getPrintJob(WToolkit.java:632)
at MultiPrint$PrintJobThread.run(MultiPrint.java:50)
at java.lang.Thread.run(Thread.java:619)

java.awt.print.PrinterException: Invalid name of PrintService.
at sun.awt.windows.WPrinterJob.setNativePrintService(Native Method)
at sun.awt.windows.WPrinterJob.getPrintService(WPrinterJob.java:573)
at sun.print.PrintJob2D.printDialog(PrintJob2D.java:392)
at sun.awt.windows.WToolkit.getPrintJob(WToolkit.java:632)
at MultiPrint$PrintJobThread.run(MultiPrint.java:50)
at java.lang.Thread.run(Thread.java:619)

This is reproduced on WinXP with a Xerox Docuprint N4025 printer with Mustang-b89. This is not reproducible on Tiger-FCS on the same machine. When I reduce the heap size to 8MB the problem becomes visible quickly. It appears like a regression in Mustang.

I have attached a sample test. Execute the sample test (if you want to see the exceptions quickly, bring down the heap size). Allow the test to run for some loops. You will see the above exceptions on the console.

Comments
EVALUATION The exception in the description is fixed by the fix for 6446094 as we should now initialise the media only once. However the test has problems which make it not a valid test for the PrintJob case - it asks every thread to print to the same file. The principal exceptions I then see are specified exceptions to the app that the file cannot be written to. If the test is modified to create a new file for each thread, no such exceptions are seen in a build with the fix for 6446094. Then we run into the next problems with the text : it creates an unlimited number of thread, and at some point the VM will run out of memory to do so. That is where VM tuning would come in and its not a bug .. I am closing this as a dup of 6446094
27-07-2007

EVALUATION Its not clear that there really is a regression. We can see the same huge increase in process size in 1.5.0_06 and unless you reduce the heap size its really hard to encounter any problems. Plus the way the test case is structured is : while (true) } spawn 3 threads sleep } ie it does not wait for the threads to join and the result is that if the sleep is less than the time for the threads to complete that you accumulate threads that are waiting to run. There were > 2000 live threads in one 1.6 run. And the growth in process size is all native - not java heap - so its probably the size of the windows thread and its stacks and any native structures allocated by java to interface to it that are taking up the process space. OOM may then be simply because there is no swap left on the machine! So this is a real stress test, mostly of things unrelated to printing. The one thing that seems hard to explain is why it takes so long for the thread to execute some printing operations which leads to its execution time being longer than the sleep. But since we see this in 1.5.0u6 then this isn't a regression
28-07-2006

EVALUATION I can now reproduce the exceptions and confirmed that it's a regression from 1.5.x.
26-07-2006

EVALUATION Looks like another memory leak bug. I could not get the exact exceptions but I'm getting OutOfMemory error and the different exceptions here must have been triggered by memory leak.
25-07-2006