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