harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Kuksenko" <sergey.kukse...@gmail.com>
Subject Re: [classlib][luni] TreeMap woes
Date Fri, 07 Dec 2007 20:33:47 GMT
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.

On 12/7/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Sergey Kuksenko wrote:
> > I found a bug.
> > Let's wait until I am checking.
> Only if you promise it is the last bug ;-)  Why cram it in now and
> suffer these new bugs and crashes?
> I believe the skill in making a release is knowing what to leave out,
> not how much you can squeeze in at the last minute.
> Regards,
> Tim
> > On 12/7/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
> >> This change to TreeMap seems to have introduced an instability, and I
> >> would say it is a candidate for reverting in M4.
> >>
> >> WDYT?
> >>
> >> ---
> >> Sergey Kuksenko.
> >> Intel Enterprise Solutions Software Division.
> >

Best regards,
Sergey Kuksenko.
Intel Enterprise Solutions Software Division.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message