harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Kuksenko (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-5248) [classlib][luni][EUT] r599829 caused regression in 5 suites
Date Fri, 07 Dec 2007 20:35:43 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-5248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549554
] 

Sergey Kuksenko commented on HARMONY-5248:
------------------------------------------

Hi All,

I really found a bug. But I wish to note, that it is a bug in Eclipse.
The story:
In order to caught that I've created a "mixed" TreeMap. The mixed tree map aggregates two
TreeMaps - old implementation and new implementation. Also mixed TreeMap performs all operation
on both maps and compared results. Using that I've cought the place where differentce occures.
It was operation remove originally from TreeSet.
Let see.
Before we have two identical maps:

Old -  { 43731146; 91780893; 92440425; }
New - { 43731146; 91780893; 92440425; }

Numbers are identityHashCode values.
Element "91780893" comes to remove.
After remove we got two different maps:

Old -  { 43731146; 92440425; }
New - { 43731146; 91780893; 92440425; }

 If we have (before remove) elements in this order(for both threes) - it means that elements
has the following order  43731146 < 91780893 < 92440425
BUT! I found that Eclipse's comparator used here changed the behaviour.
According to my logs,  sign(cmp(43731146,91780893)) == 1 that means that 43731146 > 91780893


If we compare "key to remove" with all element we got the follwoing signs: -1,0,-1. This is
a error.
Why RI doesn't fail at this case. It's happiness. Because of on RI 91780893 (key to remove)
is on root and we compare key with the root first, got equality and all ok. Occaisionally.
On my implementation we do the comparison 91780893 with 43731146(first element), got the fact
that "key to remove" is less then smallest element in Tree and we have nothing to remove.

So I think we shouldn't rollback the pacth, but it makes sence to find a error in Eclipse
and fill a bug against them.


Note, as wrote before, I found one bug in TreeMap. But, the can't impact on Eclipse unit tests,
because of according my logs all trees in EUT smaller then 100. But the bug can took a place
with small probability for trees more then 64*3 elemens and can't be for trees with size smaller
then 3*64.


> [classlib][luni][EUT] r599829 caused regression in 5 suites
> -----------------------------------------------------------
>
>                 Key: HARMONY-5248
>                 URL: https://issues.apache.org/jira/browse/HARMONY-5248
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>    Affects Versions: 5.0M4
>         Environment: x86
>            Reporter: Ilya Berezhniuk
>             Fix For: 5.0M4
>
>
> There is a regression in EUT33 on both Windows and Linux, see:
> http://people.apache.org/~smishura/r600034/Windows_x86/eut33/
> http://people.apache.org/~smishura/r600034/Linux_x86/eut33/
> I've found that breaking commit is r599829:
>     Patch for HARMONY-5232 "[classlib][luni] TreeMap bug fixing and performance improvements."
> I checked on Windows/x86 (the list of failures appeared is similar on Linux), so I did
not check that 1 unexpected failure in jdttext suite on Linux is introduced by this commit.
> Anyway, the failures in coreresources, jdtcorebuilder, pdeui, teamcore, ui suites are
because of this commit.

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