[
https://issues.apache.org/jira/browse/DERBY-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637819#action_12637819
]
Kristian Waagan commented on DERBY-3875:
----------------------------------------
Thanks Myrna.
I confirmed this on my Windows machine. This is not my primary developer
platform, and for some reason Derby was built with insane, even though my ant
properties file said sane.
A quick investigation revealed the following assert as the cause -
AllocPage.ReadContainerInfo, line 597: (code reformatted for brevity)
public static void ReadContainerInfo(byte[] containerInfo, byte[]
epage) {
int N = (int)epage[BORROWED_SPACE_OFFSET];
if (SanityManager.DEBUG) {
if (N != containerInfo.length)
SanityManager.THROWASSERT("N not what is
expected : " + N); <---- THIS ONE IS TRIGGERED
if (BORROWED_SPACE_OFFSET + BORROWED_SPACE_LEN + N
>= MAX_BORROWED_SPACE) {
SanityManager.THROWASSERT("exceed max
borrowable space: " + N);
}
}
if (N != 0)
System.arraycopy(epage,
BORROWED_SPACE_OFFSET+BORROWED_SPACE_LEN, containerInfo, 0, N);
}
Disabling the triggered assert makes the repro pass.
I'm not sure how to handle this issue, but we do need the repro to pass for
sane builds. A few ideas:
- disable assert
- make the catch clause in RAFContainer.openContainer broader to close the
file handles on any error
Any other ideas?
> Derby cannot replace a database after encountering corruption
> -------------------------------------------------------------
>
> Key: DERBY-3875
> URL: https://issues.apache.org/jira/browse/DERBY-3875
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.4.2.0
> Environment: ------------------ Java Information ------------------
> Java Version: 1.6.0_06
> Java Vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jre1.6.0_06
> Java classpath:
> C:\Working\Derby-fileclose-fix\bin;C:\Working\Derby-fileclose-fix\lib\derby.jar
> OS name: Windows XP
> OS architecture: x86
> OS version: 5.1
> Java user name: Administrator
> Java user home: C:\Documents and Settings\Administrator
> Java user dir: C:\Working\Derby-fileclose-fix
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.6
> --------- Derby Information --------
> JRE - JDBC: Java SE 6 - JDBC 4.0
> [C:\Working\Derby-fileclose-fix\lib\derby.jar] 10.4.2.0 - (689064)
> ------------------------------------------------------
> ----------------- Locale Information -----------------
> ------------------------------------------------------
> Reporter: Jason McLaurin
> Attachments: derby-3875-BackupRestoreTest.diff,
> derby-3875-BackupRestoreTest.stat, DERBY-3875_tst1.diff,
> FileCloseBugDemo.java, FileCloseBugDemo.java, RAFContainerPatch.txt
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> When Derby encounters a corrupt data file, it does not close the data file
> before throwing an exception to the caller. If the user tries to replace the
> database with a backup in response to the corruption, Derby will first
> attempt to delete the contents of the corrupt database. But since the
> corrupt file was never closed, it cannot be deleted, and Derby fails to start.
> The attached java code should reproduce the problem, and the attached patch
> should fix it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
