Bug #13204 Memory Leak in 3.1.10
Submitted: 14 Sep 2005 21:05 Modified: 15 Sep 2005 12:26
Reporter: Prishant Mantrao Email Updates:
Status: Can't repeat Impact on me:
None 
Category:Connector / J Severity:S2 (Serious)
Version:3.1.10 OS:Windows (Windows XP)
Assigned to: CPU Architecture:Any

[14 Sep 2005 21:05] Prishant Mantrao
Description:
Memory Leak in 3.1.10 ConnectorJ. After upgarding from 3.0.1 to 3.1.10 my app suddenly satrted throwing OutOfMemory Exceptions and going back to 3.0.1 fixes  it.

How to repeat:

 Upgrade from 3.0.1 to 3.1.10
[15 Sep 2005 12:26] Mark Matthews
There are no known memory leaks in Connector/J 3.1.10. We have quite a few users using it in production in heavy-load deployments as well, so we'd hear about memory leaks right away.

One difference between Connector/J 3.0 and 3.1 is that 3.1 is much pickier about requiring applications to call .close() on all resources they use (statements, result sets), because it's required by the JDBC specification.

Please ensure that all code paths in your application call .close() on the statements and result sets it creates.

(This can _appear_ to be a memory leak, since resources are not getting released until the connection is finally closed, which in a connection pooling environment might not happen for quite a while).
[15 Sep 2005 16:27] Mark Matthews
We can't diagnose this based on the information you've given. I'm not saying that C/J isn't at fault here, but we've got a lot of people using it in the field without any memory leaks. Unless you have a backtrace of object allocations, or output from a memory profiler, there's not a lot we can do here to help you, unfortunately, especially given that your app is running inside Tomcat, which has been known to have memory leaks from time-to-time, so the problem is not isolated.

If you can extract your example into a _standalone_ Java program, and it still has memory leaks, then we might be able to reproduce it here.
[15 Sep 2005 16:40] Mark Matthews
Can you attach your profiler's report, maybe it can give us some insight?
[15 Sep 2005 19:06] Mark Matthews
Are you saying the application in the JVM leaks memory, or the MySQL _server_ (that's two different things).

If the _server_ leaks memory, what does adding "useServerPrepStmts=false" do to the situation?
[15 Sep 2005 20:08] Mark Matthews
If dontTrackOpenResources=true is enabled and your problem goes away, then it means _your_ application (or something it depends on, such as DBCP) is leaking statements or result sets. 

If you enable "useUsageAdvisor=true", the driver will log where in your application results and statements were created that were never closed once the connection closes (as long as you haven't enabled "dontTrackOpenResources", that is).
[21 Sep 2005 9:45] Christian Franzel
It might by related to a different behaviour in ResultSet::getStatement(). In the older version (at least in 2.0 the following code would release all the ressources:

try {
	resultSet.close();
} finally {
	Statement stmt = resultSet.getStatement();
	if (stmt != null) {
		stmt.close();
	}
}

In the 3.1.10 version (don't know when that changed) the resultSet will return null after it has been closed, so the code above now lets the statement dangling. As there is no explicit specification on the method to return null after invoking close I consider this as a bug but that may be arguable. Anyway... first obtaining the reference to the statement and then closing resultSet and statement will work and maybe that is the cause of the troubles in the described case.