[
https://issues.apache.org/jira/browse/DERBY-4200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-4200:
----------------------------------
Component/s: Test
The problem in this case was that the finalizer work was not complete when the
OOM was thrown. With DERBY-3337 the conversion of derbyStress, the test was
changed to call Runtime.runFinalization() if it ran low on memory thus avoiding
the OOM.
The new test has been moved to the memory suite and is called
MemoryLeakFixesTest. The memory suite should be run with -Xmx16M or with the
ant junit-lowmem target to make sure it runs with a low maximum heap.
> 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, Test
> 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
> Assignee: Kathey Marsden
> Fix For: 10.5.3.2, 10.6.2.3, 10.7.1.4, 10.8.1.6, 10.9.0.0
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
