JDK-6931561 : LogManager still causes a memory leak
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.logging
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2010-03-03
  • Updated: 2011-02-16
  • Resolved: 2010-09-14
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :


A DESCRIPTION OF THE PROBLEM :
The java.util.LogManager was reported to hold strong references to logger instances and hence is a potential memory leak. Now this was fixed by replacing the strong with weak references in a normal hashtable (I refer to the evaluation of Bug 4811930). The problem with this fix is that stale entries are never removed. Only when a logger is accessed per name the hasmap entry is potentially removed (given the weak reference is stale). Simply fetching loggers with changing names leads to an out of memory error.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The LogManager has to expunge stale entries systemacially and the memory usage should not increase when no references to the fetched loggers are held.
ACTUAL -
Memory consumption steadily increases leading to an out of memory.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread main.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class TestLogManager
{
	public static void main(String[] args)
	{
		long i=0;
		while(true)
		{
			Logger.getLogger("logger_"+(i++));
			if(i%10000==0)
			{
				System.out.println("Mem: "+(Runtime.getRuntime().totalMemory()-Runtime.getRuntime().freeMemory()));
			}
		}
	}
}
---------- END SOURCE ----------

Comments
EVALUATION I queried Nelson on 2010.06.16 and 2010.07.30 and did not get a response to either e-mail. I'm going ahead and closing this bug as a duplicate of 6942989.
14-09-2010

EVALUATION Some, if not all, of this bug is being addressed by the following bug: 6942989 2/2 Memory leak of java.lang.ref.WeakReference objects Normally I close newer bugs as duplicates of older bugs, but, in this case, the newer bug is a higher priority and it is also escalated. Escalations have certain baggage in internal Oracle/Sun processes so it would not be a "good thing" (TM) for me to close the escalated bug. I'll double check with Nelson to make sure that he concurs that this bug is a duplicate of 6942989.
14-06-2010