I also recall that the problem was limited to ACF, and did not appear in BD or Railo, unfortunately at the time those platforms weren’t options that we could have considered.

Have you checked the results on some later versions of ACF as well, or perhaps even Railo? I just thought, that if you may still have the setup somewhere, you could verify it.

Gert

I think there may be something else going on here. I have reproduced your Part II test, and initially I saw the same results in the JRockit Memory Leak Detector that you’ve shown. But then, something weird happened. Let me explain:

Part II in CFMX 6,1,0,63958:

In an attempt to ‘solve’ the issue, I went through a variety of modifications to your code. For example, in the doSomething() function I created a locally scoped ‘holder’ variable and used that to create the object before appending to the return array:

<cfset var tmpHolder = "" />

<cfloop from="1" to="100" index="idx">
<cfset tmpHolder=createObject("component","testChild").init() />
<cfset arrayAppend(arrayToReturn,tmpHolder) />
</cfloop>

Also, as you can see in the code above I created a secondary CFC (testChild). This made it clearer for me in the Leak Detector screen to see the separation of the test.cfc and its loop-of-100 spawn. The testChild CFC contains only one function, an init() that simply returns THIS.

Neither of these did anything to your results. I still received the exact same 100 lingering child elements you’ve demonstrated. To be honest, I was hoping that the local ‘tmpHolder’ would have helped… somehow.

Here’s where it gets weird.

I restarted the CF service and the Leak Detector and tested a slightly different situation. I created a new CFM page, "testOther.cfm" that contained only one line of code:

<cfoutput>#now()#</cfoutput>

Then, I loaded the new testOther.cfm in a browser then immediately loaded the original test.cfm. The results were very different. This time, 100 testChild elements cleared up completely!

So I tried again… this time I loaded the original test.cfm FIRST; then the testOther.cfm. The elements stayed in memory again, not clearing until the Application expired.

I did these two tests about a dozen times (letting the Application exipre between) and each time if I loaded "testOther.cfm" first, the testChild elements cleared; and when I loaded your "test.cfm" first, the testChild elements stayed as in your example. I tested both sequences with single page loads, with multiple page loads, and mixed loads of both templates. The results were the same…. depending on which template was loaded first caused different outcomes of the scenario.

???

- Are we 100% confident that the Leak Detector is showing the correct data?

- Is there a possibility that the CF caching Steven Erat and Sean Corfield mentioned is showing us inconclusive results in the Leak Detector?

- If we assume that this code is ‘leaky’ all of the time, what could be hiding the leak during these other tests?

-If we assume that the code is never ‘leaky’, what are we viewing that makes it seem broken?

I’m running CFMX7.0.1, Win2K3, SUN JVM 1.4.2_08

Sun 1.4.2_08
Sun 1.4.2_13
Sun 1.5.0_09
BEA 1.5.0_06

All produce virtually identical results. In my opinion, this would eliminate the jvm version as a culprit, unless this is still an outstanding issue with Sun.

While it certainly good to remove a buggy JVM from the stack, I’m fairly sure CF proper is the culprit.

Thanks for keeping on this Mike!

http://www.schierberl.com/cfblog/index.cfm/2006/10/25/memoryLeaks_session

-Mike