[
https://issues.apache.org/jira/browse/DERBY-4200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mamta A. Satoor updated DERBY-4200:
-----------------------------------
Attachment: vmware10_5_SR10HeapDump.phd
vmware10_5_SR7HeapDump.phd
windows10_5_HeapDump.phd
I changed derbyStress.java's testDerby3316() method to gc() and then to dump
the heap in my 10.5 codeline. I ran this changed derbyStress in following 3
scenarios
1)my Windows XP box with IBM 1.5 jdk. Heap dump is attached as
windows10_5_HeapDump.phd
2)on the vmware machine(vmware is where we have been seeing intermittent out of
memory errors) using IBM 1.5 SR7 jdk. Heap dump is attached as
vmware10_5_SR7HeapDump.phd
3)on the vmware using IBM 1.5 SR10 jdk. Heap dump is attached as
vmware10_5_SR10HeapDump.phd
In each of these dumps, using the HeapAnalyzer, I searched for
org/apache/derby/client/net/NetStatement objects.
1)On Windows XP box, I only found 9 org/apache/derby/client/net/NetStatement
objects
2)On vmware with IBM 1.5 SR7, I found 310
org/apache/derby/client/net/NetStatement objects
3)On vmware with IBM 1.5 SR10, I found 80
org/apache/derby/client/net/NetStatement objects
So, there is definitely improvement over number of objects from IBM 1.5 SR7 to
IBM 1.5 SR10 on vmware. I wonder if the experiment above makes this more of a
platform issue vs regression?
BTW, after my changes, the derbyStress method in question looks as follows(the
changes are 3 lines under the comment //Following 3 lines are to dump the heap)
public static void testDerby3316() throws Exception {
System.out.println("DERBY-3316: Multiple statement executions ");
Connection conn = ij.startJBMS();
Statement s = conn.createStatement();
s.executeUpdate("CREATE TABLE TAB (col1 varchar(32672))");
PreparedStatement ps = conn.prepareStatement("INSERT INTO TAB
VALUES(?)");
ps.setString(1,"hello");
ps.executeUpdate();
ps.setString(1,"hello");
ps.executeUpdate();
ps.close();
for (int i = 0; i < 2000; i++)
{
s = conn.createStatement();
ResultSet rs = s.executeQuery("SELECT * from tab");
// drain the resultset
while (rs.next());
// With DERBY-3316, If I don't explicitly close the resultset
or
// statement, we get a leak.
//rs.close();
//s.close();
}
//Following 3 lines are to dump the heap
System.gc();
com.ibm.jvm.Dump.HeapDump();
com.ibm.jvm.Dump.JavaDump();
// close the connection to free up all the result sets that our
sloppy
// user didn't close.
conn.close();
conn = ij.startJBMS();
s = conn.createStatement();
s.executeUpdate("DROP TABLE TAB");
s.close();
conn.close();
}
> client side OutOfMemoryError running derbnetclientmats:jdbcapi/derbyStress
> --------------------------------------------------------------------------
>
> Key: DERBY-4200
> URL: https://issues.apache.org/jira/browse/DERBY-4200
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.5.2.0
> Environment: java version "1.5.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build pxi32devifx-20070806
> (SR5a))
> IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20070426
> (JIT enabled)
> J9VM - 20070420_12448_lHdSMR
> JIT - 20070419_1806_r8
> GC - 200704_19)
> JCL - 20070725
> SUSE linux running on vmware.
> Reporter: Kathey Marsden
> Attachments: heapdump.20090428.084024.25679.phd,
> javacore.20090428.084024.25679.txt, vmware10_5_SR10HeapDump.phd,
> vmware10_5_SR7HeapDump.phd, windows10_5_HeapDump.phd
>
>
> On the nightly run for 4/27 - 10.5.1.2 - (769232), I saw client
> jdbcapi/derbystress.java run out of heap space. The test has not failed
> like this before on the same machine with the same JVM, and the one checkin
> on that day DERBY-3991 could not account for this failure.
> I will attach the javacore and heapdump. Taking a quick look at the heap
> dump, it seems to have a lot of client side Statement objects, which seems to
> be just the leak the test is checking for. Note: the test runs with 64MB
> heap. It would be interesting to run with other jvms and force a gc() and a
> heap dump at this point in the test and see if we still have a lot of
> Statement objects or if this is a specific platform/JVM issue.
> The trace at the time of failure was :
> 1XMCURTHDINFO Current Thread Details
> NULL ----------------------
> 3XMTHREADINFO "main" (TID:0x0808D300, sys_thread_t:0x0805CBC8, state:R,
> native ID:0x0000644F) prio=5
> 4XESTACKTRACE at
> org/apache/derby/client/am/Cursor.allocateCharBuffer(Bytecode PC:77(Compiled
> Code))
> 4XESTACKTRACE at
> org/apache/derby/client/net/NetStatementReply.parseSQLDTARDarray(Bytecode
> PC:77(Compiled Code))
> 4XESTACKTRACE at
> org/apache/derby/client/net/NetStatementReply.parseQRYDSC(Bytecode
> PC:10(Compiled Code))
> 4XESTACKTRACE at
> org/apache/derby/client/net/NetStatementReply.parseOpenQuery(Bytecode
> PC:104(Compiled Code))
> 4XESTACKTRACE at
> org/apache/derby/client/net/NetStatementReply.parseOPNQRYreply(Bytecode
> PC:14(Compiled Code))
> 4XESTACKTRACE at
> org/apache/derby/client/net/NetStatementReply.readOpenQuery(Bytecode
> PC:6(Compiled Code))
> 4XESTACKTRACE at
> org/apache/derby/client/net/StatementReply.readOpenQuery(Bytecode
> PC:7(Compiled Code))
> 4XESTACKTRACE at
> org/apache/derby/client/net/NetStatement.readOpenQuery_(Bytecode
> PC:11(Compiled Code))
> 4XESTACKTRACE at
> org/apache/derby/client/am/Statement.readOpenQuery(Bytecode PC:6(Compiled
> Code))
> 4XESTACKTRACE at
> org/apache/derby/client/am/Statement.flowExecute(Bytecode PC:581(Compiled
> Code))
> 4XESTACKTRACE at
> org/apache/derby/client/am/Statement.executeQueryX(Bytecode PC:3(Compiled
> Code))
> 4XESTACKTRACE at
> org/apache/derby/client/am/Statement.executeQuery(Bytecode PC:3(Compiled
> Code))
> 4XESTACKTRACE at
> org/apache/derbyTesting/functionTests/tests/jdbcapi/derbyStress.testDerby3316(derbyStress.java:156)
> 4XESTACKTRACE at
> org/apache/derbyTesting/functionTests/tests/jdbcapi/derbyStress.main(derbyStress.java:57(Compiled
> Code))
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
