You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by Joseph Siddal <jo...@omlet.co.uk> on 2014/04/10 13:50:21 UTC
possible memory leak PDFBox 2.0.0
Hi,
I've found a memory leak that is caused when doing high volumes of printing.
The code that reproduces the bug is attached. The code just continuously
sends the same printjob to the default printer. The pdf I'm using is
available here <https://www.dropbox.com/s/7k2uzn0w0fkue11/job.pdf>. The
memory leak is evident after 6mins of running the code. The
sun.print.CustomMediaTray has 2 static ArrayList fields which are
continuously growing in size going from size 29000 to 10000+ after 6
minutes and continuing to climb.
This is using OSX Mavericks, JDK 1.8.0.
Any help would be appreciated.
Regards
Joseph
Re: possible memory leak PDFBox 2.0.0
Posted by John Hewson <jo...@jahewson.com>.
Yes, this is a good suggestion, it looks like the JVM is statically caching some
information related to custom media (i.e. Paper). There’s not really anywhere
where it looks like PDFBox could be responsible for this. It certainly wouldn’t
be the first JVM bug we’ve found...
-- John
On 11 Apr 2014, at 21:50, Tilman Hausherr <TH...@t-online.de> wrote:
> Another thought:
> Would it work if you use only one paper object, i.e. do "new Paper()" only once?
>
> Tilman
>
> Am 10.04.2014 17:29, schrieb Joseph Siddal:
>> Hi Maruan,
>>
>> The code to reproduce it is:
>>
>> import org.apache.pdfbox.rendering.printing.Scaling;
>> import org.apache.pdfbox.rendering.printing.Orientation;
>> import org.apache.pdfbox.pdmodel.PDDocument;
>> import org.apache.pdfbox.rendering.PDFPrinter;
>>
>> import java.awt.print.Paper;
>>
>> public class PdfBoxExample {
>>
>> public static void main(String[] args) throws Exception {
>> String fileName = args[1];
>>
>> while (true) {
>> Paper paper = new Paper();
>> int width = 4, height = 6;
>> paper.setSize(width * 72, height * 72);
>> paper.setImageableArea(0, 0, width * 72, height * 72);
>> PDDocument pdf=PDDocument.load(fileName);
>> PDFPrinter printer = new PDFPrinter(pdf, Scaling.SCALE_TO_FIT,
>> Orientation.AUTO, paper);
>> printer.silentPrint();
>> pdf.close();
>> System.gc();
>> }
>> }
>>
>> }
>>
>>
>>
>> On 10 April 2014 16:15, Maruan Sahyoun <sa...@fileaffairs.de> wrote:
>>
>>> Hi Joseph,
>>>
>>> the attachments didn't make it to the mailing list. Could you upload it to
>>> a public location? Id the behavior reproducible with any PDF or only with
>>> some. Could you oplad a sample PDF too?
>>>
>>> BR
>>> Maruan Sahyoun
>>>
>>> Am 10.04.2014 um 13:50 schrieb Joseph Siddal <jo...@omlet.co.uk>:
>>>
>>>> Hi,
>>>>
>>>> I've found a memory leak that is caused when doing high volumes of
>>> printing.
>>>> The code that reproduces the bug is attached. The code just continuously
>>> sends the same printjob to the default printer. The pdf I'm using is
>>> available here. The memory leak is evident after 6mins of running the code.
>>> The sun.print.CustomMediaTray has 2 static ArrayList fields which are
>>> continuously growing in size going from size 29000 to 10000+ after 6
>>> minutes and continuing to climb.
>>>> This is using OSX Mavericks, JDK 1.8.0.
>>>>
>>>> Any help would be appreciated.
>>>>
>>>> Regards
>>>> Joseph
>>>
>
Re: possible memory leak PDFBox 2.0.0
Posted by Tilman Hausherr <TH...@t-online.de>.
Another thought:
Would it work if you use only one paper object, i.e. do "new Paper()"
only once?
Tilman
Am 10.04.2014 17:29, schrieb Joseph Siddal:
> Hi Maruan,
>
> The code to reproduce it is:
>
> import org.apache.pdfbox.rendering.printing.Scaling;
> import org.apache.pdfbox.rendering.printing.Orientation;
> import org.apache.pdfbox.pdmodel.PDDocument;
> import org.apache.pdfbox.rendering.PDFPrinter;
>
> import java.awt.print.Paper;
>
> public class PdfBoxExample {
>
> public static void main(String[] args) throws Exception {
> String fileName = args[1];
>
> while (true) {
> Paper paper = new Paper();
> int width = 4, height = 6;
> paper.setSize(width * 72, height * 72);
> paper.setImageableArea(0, 0, width * 72, height * 72);
> PDDocument pdf=PDDocument.load(fileName);
> PDFPrinter printer = new PDFPrinter(pdf, Scaling.SCALE_TO_FIT,
> Orientation.AUTO, paper);
> printer.silentPrint();
> pdf.close();
> System.gc();
> }
> }
>
> }
>
>
>
> On 10 April 2014 16:15, Maruan Sahyoun <sa...@fileaffairs.de> wrote:
>
>> Hi Joseph,
>>
>> the attachments didn't make it to the mailing list. Could you upload it to
>> a public location? Id the behavior reproducible with any PDF or only with
>> some. Could you oplad a sample PDF too?
>>
>> BR
>> Maruan Sahyoun
>>
>> Am 10.04.2014 um 13:50 schrieb Joseph Siddal <jo...@omlet.co.uk>:
>>
>>> Hi,
>>>
>>> I've found a memory leak that is caused when doing high volumes of
>> printing.
>>> The code that reproduces the bug is attached. The code just continuously
>> sends the same printjob to the default printer. The pdf I'm using is
>> available here. The memory leak is evident after 6mins of running the code.
>> The sun.print.CustomMediaTray has 2 static ArrayList fields which are
>> continuously growing in size going from size 29000 to 10000+ after 6
>> minutes and continuing to climb.
>>> This is using OSX Mavericks, JDK 1.8.0.
>>>
>>> Any help would be appreciated.
>>>
>>> Regards
>>> Joseph
>>
Re: possible memory leak PDFBox 2.0.0
Posted by Joseph Siddal <jo...@omlet.co.uk>.
Hi Maruan,
The code to reproduce it is:
import org.apache.pdfbox.rendering.printing.Scaling;
import org.apache.pdfbox.rendering.printing.Orientation;
import org.apache.pdfbox.pdmodel.PDDocument;
import org.apache.pdfbox.rendering.PDFPrinter;
import java.awt.print.Paper;
public class PdfBoxExample {
public static void main(String[] args) throws Exception {
String fileName = args[1];
while (true) {
Paper paper = new Paper();
int width = 4, height = 6;
paper.setSize(width * 72, height * 72);
paper.setImageableArea(0, 0, width * 72, height * 72);
PDDocument pdf=PDDocument.load(fileName);
PDFPrinter printer = new PDFPrinter(pdf, Scaling.SCALE_TO_FIT,
Orientation.AUTO, paper);
printer.silentPrint();
pdf.close();
System.gc();
}
}
}
On 10 April 2014 16:15, Maruan Sahyoun <sa...@fileaffairs.de> wrote:
> Hi Joseph,
>
> the attachments didn't make it to the mailing list. Could you upload it to
> a public location? Id the behavior reproducible with any PDF or only with
> some. Could you oplad a sample PDF too?
>
> BR
> Maruan Sahyoun
>
> Am 10.04.2014 um 13:50 schrieb Joseph Siddal <jo...@omlet.co.uk>:
>
> > Hi,
> >
> > I've found a memory leak that is caused when doing high volumes of
> printing.
> >
> > The code that reproduces the bug is attached. The code just continuously
> sends the same printjob to the default printer. The pdf I'm using is
> available here. The memory leak is evident after 6mins of running the code.
> The sun.print.CustomMediaTray has 2 static ArrayList fields which are
> continuously growing in size going from size 29000 to 10000+ after 6
> minutes and continuing to climb.
> >
> > This is using OSX Mavericks, JDK 1.8.0.
> >
> > Any help would be appreciated.
> >
> > Regards
> > Joseph
>
>
Re: possible memory leak PDFBox 2.0.0
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi Joseph,
the attachments didn’t make it to the mailing list. Could you upload it to a public location? Id the behavior reproducible with any PDF or only with some. Could you oplad a sample PDF too?
BR
Maruan Sahyoun
Am 10.04.2014 um 13:50 schrieb Joseph Siddal <jo...@omlet.co.uk>:
> Hi,
>
> I've found a memory leak that is caused when doing high volumes of printing.
>
> The code that reproduces the bug is attached. The code just continuously sends the same printjob to the default printer. The pdf I'm using is available here. The memory leak is evident after 6mins of running the code. The sun.print.CustomMediaTray has 2 static ArrayList fields which are continuously growing in size going from size 29000 to 10000+ after 6 minutes and continuing to climb.
>
> This is using OSX Mavericks, JDK 1.8.0.
>
> Any help would be appreciated.
>
> Regards
> Joseph
Re: possible memory leak PDFBox 2.0.0
Posted by Tilman Hausherr <TH...@t-online.de>.
It is just a guess...
I looked at the printing code and couldn't find anything like "dispose"
or "close".
Btw "29000 to 10000+" is shrinking.
The best would probably be to use the profiler to find out who is
generating that class.
Tilman
Am 11.04.2014 12:09, schrieb Joseph Siddal:
> Hi Tilman,
>
> My application does high volumes of printing over the course of a day so
> this memory leak takes a few hours before it becomes a problem. My Demo
> code just accelerates the memory leak.
>
> The file is being printed. are you saying the fields should shrink once the
> file is printed?
>
> Regards
> Joseph
>
>
>
> On 10 April 2014 18:17, Tilman Hausherr <TH...@t-online.de> wrote:
>
>> Hi Joseph,
>>
>> Just a thought - could it be that this fields grow and grow because the
>> file is never printed? (Obviously, you don't want to print thousands of
>> print jobs)
>>
>> Tilman
>>
>> Am 10.04.2014 13:50, schrieb Joseph Siddal:
>>
>>> Hi,
>>>
>>> I've found a memory leak that is caused when doing high volumes of
>>> printing.
>>>
>>> The code that reproduces the bug is attached. The code just continuously
>>> sends the same printjob to the default printer. The pdf I'm using is
>>> available here <https://www.dropbox.com/s/7k2uzn0w0fkue11/job.pdf>. The
>>> memory leak is evident after 6mins of running the code. The
>>> sun.print.CustomMediaTray has 2 static ArrayList fields which are
>>> continuously growing in size going from size 29000 to 10000+ after 6
>>> minutes and continuing to climb.
>>>
>>>
>>> This is using OSX Mavericks, JDK 1.8.0.
>>>
>>> Any help would be appreciated.
>>>
>>> Regards
>>> Joseph
>>>
>>
Re: possible memory leak PDFBox 2.0.0
Posted by Joseph Siddal <jo...@omlet.co.uk>.
Hi Tilman,
My application does high volumes of printing over the course of a day so
this memory leak takes a few hours before it becomes a problem. My Demo
code just accelerates the memory leak.
The file is being printed. are you saying the fields should shrink once the
file is printed?
Regards
Joseph
On 10 April 2014 18:17, Tilman Hausherr <TH...@t-online.de> wrote:
> Hi Joseph,
>
> Just a thought - could it be that this fields grow and grow because the
> file is never printed? (Obviously, you don't want to print thousands of
> print jobs)
>
> Tilman
>
> Am 10.04.2014 13:50, schrieb Joseph Siddal:
>
>> Hi,
>>
>> I've found a memory leak that is caused when doing high volumes of
>> printing.
>>
>> The code that reproduces the bug is attached. The code just continuously
>> sends the same printjob to the default printer. The pdf I'm using is
>> available here <https://www.dropbox.com/s/7k2uzn0w0fkue11/job.pdf>. The
>> memory leak is evident after 6mins of running the code. The
>> sun.print.CustomMediaTray has 2 static ArrayList fields which are
>> continuously growing in size going from size 29000 to 10000+ after 6
>> minutes and continuing to climb.
>>
>>
>> This is using OSX Mavericks, JDK 1.8.0.
>>
>> Any help would be appreciated.
>>
>> Regards
>> Joseph
>>
>
>
Re: possible memory leak PDFBox 2.0.0
Posted by Tilman Hausherr <TH...@t-online.de>.
Hi Joseph,
Just a thought - could it be that this fields grow and grow because the
file is never printed? (Obviously, you don't want to print thousands of
print jobs)
Tilman
Am 10.04.2014 13:50, schrieb Joseph Siddal:
> Hi,
>
> I've found a memory leak that is caused when doing high volumes of
> printing.
>
> The code that reproduces the bug is attached. The code just
> continuously sends the same printjob to the default printer. The pdf
> I'm using is available here
> <https://www.dropbox.com/s/7k2uzn0w0fkue11/job.pdf>. The memory leak
> is evident after 6mins of running the code. The
> sun.print.CustomMediaTray has 2 static ArrayList fields which are
> continuously growing in size going from size 29000 to 10000+ after 6
> minutes and continuing to climb.
>
> This is using OSX Mavericks, JDK 1.8.0.
>
> Any help would be appreciated.
>
> Regards
> Joseph