tracker issue : CF-4198534

select a category, or use search below
(searches all categories and all time range)

cfchart memory leak crashes server

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/Fixed

Reporter/Name(from Bugbase): Gary Fenton / Gary Fenton ()

Created: 04/18/2017

Components: Charting/Graphing, Server

Versions: 2016

Failure Type: Memory Leak

Found In Build/Fixed In Build: Update 3 / 303875

Priority/Frequency: Normal / Some users will encounter

Locale/System: English / Win 2012 Server x64

Vote Count: 1

Problem Description: Repeated use of cfchart keeps increasing memory use until CF stops responding to requests. "Error 500 Java heap space" reported in the http status code. CF logs confirm out of memory.

Steps to Reproduce: Keep requesting a page that renders several PNG charts with cfchart. I'm using the default charting settings in CF Admin. Windows Server has 4GB RAM. Recently increased Java heap max to 2048Mb but this issue persists. Using update 3 of CF2016. No prior version installed, this is a brand new server.

Actual Result: Each page refresh makes the coldfusion.exe process consume 12Mb of memory. Repeat and after a few hours the max heap size is exceeded and requests slow down and then stop for good. CF then requires restarting. This is with just 1 users. In production the issue will manifest much quicker. Therefore CF2016 is not suitable for production use. 

Expected Result: Memory use should not increase with the same page and charts being requested. This is NOT load testing. It's just 1 user (a developer) refreshing the page as part of a normal development session. Memory doesn't appear to be managed properly in CF.

Any Workarounds: None.

Exception entry in log file:
"Error","ajp-nio-8012-exec-10","04/18/17","13:35:18","test1_secure","Java heap space The specific sequence of files included or processed is: \\myFileServer\reports_media_results.cfm'' "
java.lang.OutOfMemoryError: Java heap space
	at java.awt.image.DataBufferInt.<init>(
	at java.awt.image.Raster.createPackedRaster(
	at java.awt.image.DirectColorModel.createCompatibleWritableRaster(
	at java.awt.image.BufferedImage.<init>(
	at sun.java2d.pipe.DrawImage.makeBufferedImage(
	at sun.java2d.pipe.DrawImage.renderImageXform(
	at sun.java2d.pipe.DrawImage.transformImage(
	at sun.java2d.pipe.DrawImage.scaleImage(
	at sun.java2d.pipe.DrawImage.scaleImage(
	at sun.java2d.SunGraphics2D.drawImage(
	at sun.java2d.SunGraphics2D.drawImage(
	at com.zingchart.Context2d.jsFunction_drawImage(
	at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(
	at java.lang.reflect.Method.invoke(
	at org.mozilla.javascript.MemberBox.invoke(
	at org.mozilla.javascript.optimizer.OptRuntime.callN(
	at com.zingchart.zingchart_rhino_min._c_anonymous_250(Unknown Source)
	at Source)
	at org.mozilla.javascript.ScriptRuntime.applyOrCall(
	at org.mozilla.javascript.BaseFunction.execIdCall(
	at org.mozilla.javascript.optimizer.OptRuntime.call2(
	at com.zingchart.zingchart_rhino_min._c_anonymous_65(Unknown Source)
	at Source)
	at org.mozilla.javascript.optimizer.OptRuntime.callProp0(
	at com.zingchart.zingchart_rhino_min._c_anonymous_244(Unknown Source)
	at Source)
	at org.mozilla.javascript.ScriptRuntime.applyOrCall(
	at org.mozilla.javascript.BaseFunction.execIdCall(



Seems to be closely related to which has been closed as a "duplicate" of However, having read both of those tickets, one relates to CPU the other memory, so it looks like the memory one was incorrectly closed. They are related but NOT the same thing.
Comment by John W.
920 | April 18, 2017 01:20:44 PM GMT
We are seeing a steady increase of the memory used on CF2016 with update 3. Loading a heap dump in Eclipse Memory Analyzer shows that 70% (3.4 GB) is consumed by org.mozilla.javascript.NativeObject.
Comment by Jonas M.
921 | April 19, 2017 03:17:31 PM GMT
John: The high CPU might have been caused by constant full GCs due to the leaked memory. I've found that the following will allow the leaked memory to be garbage collected: <cfset serviceFactory = CreateObject('java', 'coldfusion.server.ServiceFactory') /> <cfset graphingService = serviceFactory.getNewGraphingService() /> <cfset field = graphingService.getClass().getDeclaredField('detachedZCComponent') /> <cfset field.setAccessible(true) /> <cfset field.set(graphingService, JavaCast('null', 0)) /> Use at your own risk.
Comment by Jonas M.
922 | April 20, 2017 12:11:18 PM GMT
@Jonas. Thanks for the code suggestion but it had no effect when I tried it. Memory usage continues to increase up to the max. Adobe have created a patch (in testing only) which has stopped CF from crashing out but still allows memory usage to reach the max from just 1 user requesting charts over a few hours. I hope there will be an update soon.
Comment by Gary F.
923 | April 21, 2017 01:30:15 AM GMT
Hi Gary, Good to hear that Adobe is working on the issue. As to the workaround I posted, it will release memory leaked up to that point but it will not prevent new memory from leaking, so it needs to be executed regularly. We don't use cfchart a lot so for us it's enough to do it once per day.
Comment by Jonas M.
924 | April 21, 2017 05:48:05 AM GMT