db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3875) Derby cannot replace a database after encountering corruption
Date Wed, 08 Oct 2008 07:59:44 GMT

    [ 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.


Mime
View raw message