MySQL Bugs: #23512: native memory leak using prepared statements

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:	None
Category:	Connector / J	Severity:	S2 (Serious)
Version:	5.0.3	OS:	Linux (SUSE Linux 9.2)
Assigned to:	Mark Matthews	CPU Architecture:	Any

Description:
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.

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.