JFreeChart.draw() causes OutOfMemoryError

[Paul Folbrecht]

I'm using JFreeChart in a servlet- drawing it to an offscreen buffer and encoding that in JPEG format. Well, the 2nd time, after starting the server (Weblogic 5.1 SP9), that draw() is called in this manner, it causes an OutOfMemoryException. In addition, no stack trace is available from the exception. I'm hoping somebody else might have come across this and there might be some workaround.

Here's the code I'm using to do the encoding:

protected void writeChartAsJPEG( JFreeChart chart, OutputStream stream ) throws IOException {
try {
BufferedImage image = new BufferedImage( 400, 400, BufferedImage.TYPE_INT_RGB );
Graphics2D graphics = image.createGraphics();
JPEGImageEncoder encoder = JPEGCodec.createJPEGEncoder( stream );
JPEGEncodeParam param;

chart.draw( graphics, new Rectangle2D.Double( 0, 0, 400, 400 ) );
param = encoder.getDefaultJPEGEncodeParam( image );
param.setQuality( 1.0f, true );
encoder.encode( image, param );
graphics.dispose();
System.gc();
}
catch ( OutOfMemoryError e ) {
Logger.error( e );
}
}

[David Gilbert]

Hi Paul,

I've not seen this behaviour before so I'm not sure what the cause may be. I know the drawing routines in JFreeChart are not as memory efficient as they could be, and I hope to improve that for a future version of the library.

I'll register this as a bug on SourceForge (tried just now but there's something going wrong at SourceForge right now) and keep an eye out for other similar reports.

If you find anything out, let me know...

Regards,

DG.

[Paul Folbrecht]

Well, I rebuilt the source (in preparation for debugging) and the problem disappeared. Perhaps I had a corrupt jar.

[Paul Folbrecht]

Turns out I spoke too soon (damnit)! Problem was still there- the indirect cause, I discovered, is sporadic bad data from a service I'm using.

The direct cause is in HorizontalNumberAxis.calculateVisibleTickCount(). If you have an empty series (zero points), this method returns the max value for a signed integer (2.1 billion+). refreshTicks() then tries to iterate through this count and eventually runs out of heap space.

I didn't fix the bug; the simpler solution is just to validate the input data.