You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kristian Waagan (JIRA)" <ji...@apache.org> on 2009/11/18 14:04:39 UTC
[jira] Updated: (DERBY-3844) ASSERT failure in BasePage.unlatch()
when running LobStreamsTest
[ https://issues.apache.org/jira/browse/DERBY-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-3844:
-----------------------------------
Attachment: derby-3844-1a-repro_test.diff
Attaching a repro for the bug.
Even though generating the junk data seems to trigger garbage collection, I added calls to do gc and finalization for good measure (I'm aware that the call to do gc may be a no-op).
The trouble in this case is the use of the pattern rs.getBlob(1).blobMethod(), followed by another operation on the same BLOB field, and combined with gc/finalization. The result set generates a new Blob object for each call to getBlob, and this object has a finalize-method closing the source stream (and unlatching the source page).
Without having studied this in detail, I think there are two main lines of fixing this:
1) Disallow calling getBlob multiple times on the same column (and the same row).
2) Make the result set smarter, or somehow make sure the source stream isn't closed too early.
(1) is the simplest, but may break existing applications (including some of our own tests for sure). I have not consulted the JDBC spec on this.
(2) is probably harder, may have performance impacts and we run the risk of introducing resource leaks (this may be cleaned up in commit/rollback anyway). I think it should be possible to get this right, but it will make the result set slightly fatter.
The discussion about calling various result set methods multiple times seems familiar, but I'm not sure we reached consensus the last time...
The Java SE 6 JavaDoc isn't very authoritative:
"For maximum portability, result set columns within each row should be read in left-to-right order, and each column should be read only once."
Having gotten this far in my post, won't this be a problem anyway if the user calls Blob.free?
Assuming obtaining multiple Blob-objects for the same BLOB field is allowed, should a Blob.free affect the other "instances"?
I fear we are about to wander off into the tall weeds, and in my opinion we should try to improve the situation such that it is clear to the user what is allowed and what isn't when it comes to LOBs and streams. I don't know how much stricter we would have to be, and I'm willing to postpone this until 11.0, but I'd rather do it earlier.
I'm far from having the overview, but note that other situations get us into trouble too. We already have Jiras logged where queries like "select blob as b1, blob as b2" cause errors.
> ASSERT failure in BasePage.unlatch() when running LobStreamsTest
> ----------------------------------------------------------------
>
> Key: DERBY-3844
> URL: https://issues.apache.org/jira/browse/DERBY-3844
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.5.1.1
> Environment: Solaris 10, AMD Opteron with 2 CPUs, Java(TM) SE Runtime Environment (build 1.6.0_06-b02), Derby trunk revision 686755
> Reporter: Knut Anders Hatlen
> Attachments: derby-3844-1a-repro_test.diff
>
>
> I saw this failure when running suites.All to test the patch nested_transaction_v2.diff which is posted on DERBY-3693. The failure did not occur when I reran the test, and I don't believe the patch should have any effect on the code that failed. The ASSERT that is triggered is this one (which indicates that we're trying to unlatch a page that's not latched):
> if (SanityManager.DEBUG) {
> SanityManager.ASSERT(isLatched());
> }
> Here's the full stack trace and thread dump:
> 1) testBlobWrite3Param(org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest)org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED
> at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:98)
> at org.apache.derby.impl.store.raw.data.BasePage.unlatch(BasePage.java:1319)
> at org.apache.derby.impl.store.raw.data.OverflowInputStream.fillByteHolder(OverflowInputStream.java:152)
> at org.apache.derby.impl.store.raw.data.BufferedByteHolderInputStream.read(BufferedByteHolderInputStream.java:44)
> at java.io.DataInputStream.read(DataInputStream.java:132)
> at org.apache.derby.impl.jdbc.PositionedStoreStream.read(PositionedStoreStream.java:106)
> at org.apache.derby.impl.jdbc.AutoPositioningStream.read(AutoPositioningStream.java:113)
> at org.apache.derby.impl.jdbc.UpdatableBlobStream.read(UpdatableBlobStream.java:194)
> at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.readBytesFromStream(LobStreamsTest.java:463)
> at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.compareLob2File(LobStreamsTest.java:488)
> at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.testBlobWrite3Param(LobStreamsTest.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:104)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> ---------------
> Stack traces for all live threads:
> Thread name=derby.antiGC id=280 priority=1 state=WAITING isdaemon=true
> java.lang.Object.wait(Native Method)
> java.lang.Object.wait(Object.java:485)
> org.apache.derby.impl.services.monitor.AntiGC.run(BaseMonitor.java:2217)
> java.lang.Thread.run(Thread.java:619)
> Thread name=Signal Dispatcher id=4 priority=9 state=RUNNABLE isdaemon=true
> Thread name=main id=1 priority=5 state=RUNNABLE isdaemon=false
> java.lang.Thread.dumpThreads(Native Method)
> java.lang.Thread.getAllStackTraces(Thread.java:1477)
> org.apache.derby.shared.common.sanity.ThreadDump.getStackDumpString(ThreadDump.java:34)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> org.apache.derby.shared.common.sanity.AssertFailure$1.run(AssertFailure.java:165)
> java.security.AccessController.doPrivileged(Native Method)
> org.apache.derby.shared.common.sanity.AssertFailure.dumpThreads(AssertFailure.java:159)
> org.apache.derby.shared.common.sanity.AssertFailure.<init>(AssertFailure.java:82)
> org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:98)
> org.apache.derby.impl.store.raw.data.BasePage.unlatch(BasePage.java:1319)
> org.apache.derby.impl.store.raw.data.OverflowInputStream.fillByteHolder(OverflowInputStream.java:152)
> org.apache.derby.impl.store.raw.data.BufferedByteHolderInputStream.read(BufferedByteHolderInputStream.java:44)
> java.io.DataInputStream.read(DataInputStream.java:132)
> org.apache.derby.impl.jdbc.PositionedStoreStream.read(PositionedStoreStream.java:106)
> org.apache.derby.impl.jdbc.AutoPositioningStream.read(AutoPositioningStream.java:113)
> org.apache.derby.impl.jdbc.UpdatableBlobStream.read(UpdatableBlobStream.java:194)
> org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.readBytesFromStream(LobStreamsTest.java:463)
> org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.compareLob2File(LobStreamsTest.java:488)
> org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.testBlobWrite3Param(LobStreamsTest.java:130)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:104)
> junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> junit.extensions.TestSetup.run(TestSetup.java:25)
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> Thread name=derby.rawStoreDaemon id=941 priority=5 state=TIMED_WAITING isdaemon=true
> java.lang.Object.wait(Native Method)
> org.apache.derby.impl.services.daemon.BasicDaemon.rest(BasicDaemon.java:571)
> org.apache.derby.impl.services.daemon.BasicDaemon.run(BasicDaemon.java:388)
> java.lang.Thread.run(Thread.java:619)
> Thread name=Timer-3 id=281 priority=5 state=WAITING isdaemon=true
> java.lang.Object.wait(Native Method)
> java.lang.Object.wait(Object.java:485)
> java.util.TimerThread.mainLoop(Timer.java:483)
> java.util.TimerThread.run(Timer.java:462)
> Thread name=Finalizer id=3 priority=8 state=WAITING isdaemon=true
> java.lang.Object.wait(Native Method)
> java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
> java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
> java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
> Thread name=Reference Handler id=2 priority=10 state=WAITING isdaemon=true
> java.lang.Object.wait(Native Method)
> java.lang.Object.wait(Object.java:485)
> java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
> Thread name=derby.rawStoreDaemon id=933 priority=5 state=TIMED_WAITING isdaemon=true
> java.lang.Object.wait(Native Method)
> org.apache.derby.impl.services.daemon.BasicDaemon.rest(BasicDaemon.java:571)
> org.apache.derby.impl.services.daemon.BasicDaemon.run(BasicDaemon.java:388)
> java.lang.Thread.run(Thread.java:619)
> ---------------
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.