db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4181) SQLState.LANG_IGNORE_MISSING_INDEX_ROW_DURING_DELETE during NsTest run
Date Fri, 08 May 2009 17:08:45 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mike Matrigali updated DERBY-4181:
----------------------------------


I believe this is some sort of BigDecimal jvm bug in ibm16 jvm's.  I have attached derby4181debug.diff
which has added debug statements in SQLDecimal.typeCompare.  The routine gets 2 
BigDecimals and then compares them.  Using the Kathey's most
recent repro, the first time this routine is called the compare of
the 2 values is incorrect.  This then leads to the btree index corruption that shows up at
various times.

I have included the derby.log and the derby.properties that I used for my run.  Using the
derby.debug.true=enableBtreeConsistencyCheck
property in SANE mode catches this problem quicker.

The debug statements also show that comparing the 2 values
twice get the wrong answer, but then after printing one of the 
values and then doing the compare you then get the right answer from the compare.

I tried repro'ing this outside of derby but did not have any luck.

Here is the interesting part from the derby.log that shows it
returning that 2959688338890040800.0000000000 < 464202.5974272370 twice and then reversing
the compare 
result after the BigDecimal with 464202.5974272370 is
printed.
:
DEBUG SQLDecimal OUTPUT: typeCompare result after 1st compare:
    otherValue.scale     = 10
    localValue.scale     = 10
    ret_val (result of localValue.compareTo(otherValue) ) = -1^M
DEBUG SQLDecimal OUTPUT: typeCompare after 2nd compare, no change in result:
    otherValue.scale     = 10
    localValue.scale     = 10
    ret_val (result of localValue.compareTo(otherValue) ) = -1^M
DEBUG SQLDecimal OUTPUT: otherValue = 464202.5974272370^M
DEBUG SQLDecimal OUTPUT: typeCompare result after printing otherValue:
    otherValue.scale     = 10
    localValue.scale     = 10
    ret_val3 (result of localValue.compareTo(otherValue) ) = 1^M
DEBUG SQLDecimal OUTPUT: localValue = 2959688338890040800.0000000000^M
DEBUG SQLDecimal OUTPUT: typeCompare result after printing otherValue:
    otherValue.scale     = 10
    localValue.scale     = 10
    ret_val2 (result of localValue.compareTo(otherValue) ) = 1^M
DEBUG SQLDecimal OUTPUT: typeCompare initial values:localValue double = 2.959688
3388900408E18otherValue.scale = 10localValue.scale = 10^M
Exception trace: ^M

> SQLState.LANG_IGNORE_MISSING_INDEX_ROW_DURING_DELETE during NsTest run 
> -----------------------------------------------------------------------
>
>                 Key: DERBY-4181
>                 URL: https://issues.apache.org/jira/browse/DERBY-4181
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.4.2.0, 10.5.1.1, 10.6.0.0
>         Environment: Suse Linux 10, IBM 1.6 SR4
>            Reporter: Myrna van Lunteren
>            Assignee: Mike Matrigali
>         Attachments: derby.log, derby.properties, derby4181debug.diff, log_excerpt_sample_assert.txt,
ReproDerby4181.derby.log, ReproDerby4181.java, ReproDerby4181.java, ReproDerby4181.out, run1serverlog.jar,
serverlog.jar
>
>
> During the NsTest runs for 10.5.1.0 and 10.5.1.1 I initially ignored warnings showing
up in the server's derby.log file:
> WARNING: While deleting a row from a table the index row for base table row (594,12)
was not found in index with conglomerate id 1,185.  This problem has automatically been corrected
as part of the delete operation.
> However, I don't think this is a completely healthy warning, I think it indicates there
was corruption in the index.
> I'll investigate further.

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