Bug #23512 native memory leak using prepared statements
Submitted: 20 Oct 2006 18:29 Modified: 23 Oct 2006 14:40
Reporter: Mark Strecker Email Updates:
Status: Not a Bug Impact on me:
Category:Connector / J Severity:S2 (Serious)
Version:5.0.3 OS:Linux (SUSE Linux 9.2)
Assigned to: Mark Matthews CPU Architecture:Any

[20 Oct 2006 18:29] Mark Strecker
I am using :
SUSE Linux 9.2
Connector/J v5.0.3
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_09-b01, mixed mode)
MySQL 4.1.12max

I have an InnoDB table and did the same query over and over(5000 for this test) and watched the JVM memory (with YourKit) and the process memory with top.
I expected the JVM reported memory and the OS reported memory to stay the same, but I saw the OS reported memory grow faster than the JVM reported memory.
At the end of the test, the OS says the process has 352MB of RAM allocated, but the JVM only has 290MB of RAM (266MB HEAP + 24 NON-HEAP). There is a 62MB native memory leak.

How to repeat:
I included a standalone Java program along with the table definition. All you need to do in put a row in the table after you create it and modify the connection URL.
[23 Oct 2006 14:40] Mark Matthews
Our JDBC driver is Type-IV, which means it's pure java, so the driver itself can't be leaking native memory.

If you see a native memory leak, it's a potential bug with your JVM, or it's "natural" overhead (there's memory the JVM needs to manage the heap that's not accounted for when you use a profiler that's only counting the size of objects in the heap, for example see http://forum.java.sun.com/thread.jspa?threadID=598888&messageID=3351661). You'd have to check with JVM vendor to determine which is the case.