harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prashanth K S <prashanth.jayash...@gmail.com>
Subject Re: [jira] Updated: (HARMONY-6681) AbstractCollection.toArray() and AbstractCollection.toArray(T[]) are broken for concurrently modified collections like ConcurrentHashMap.keySet()
Date Tue, 30 Nov 2010 17:54:44 GMT
JIRA 6678 attempts to address the same. A patch has been attached to the
JIRA and is yet to be committed. Kindly test the behavior after the fix has
been committed.

-- 
Regards
Prashanth


On Tue, Nov 30, 2010 at 10:18 PM, Uwe Schindler (JIRA) <jira@apache.org>wrote:

>
>     [
> https://issues.apache.org/jira/browse/HARMONY-6681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Uwe Schindler updated HARMONY-6681:
> -----------------------------------
>
>    Description:
> If you call ConcurrentHashMap.keySet().toArray() [as done in trunks
> Lucene's RAMDirectory#fileMap] and another thread modifies the collecton,
> you get NoSuchElementExceptions or AIOOBEs. The reason is that
> AbstractCollection.toArray methods allocate the array using the current size
> of the collection and then either iterate on the values (which is oficially
> supported by ConcurrentHashMap, its iterator is safe for concurrent
> modification!) and set them on the target without checking bounds. On the
> other hand if there are too few entries in the collection, the array is
> nulled at the end. The bad thing is that the toArray() and toArray(T[])
> methods behave differently, so depending on the modification they throw
> different exceptions (one impl simply drops entries that dont fit into the
> array).
>
> Since Java SE 6, its officially documented, how toArray must behave: [
> http://download.oracle.com/javase/6/docs/api/java/util/AbstractCollection.html#toArray(T[])<http://download.oracle.com/javase/6/docs/api/java/util/AbstractCollection.html#toArray%28T[]%29>];
> This is violated by harmony and even the fix in HARMONY-6236 does not
> respect it, leading to such bugs.
>
> Java SE 5 does not document that, but ConcurrentHashMap.keySet(), values()
> and entrySet() have own implementations of toArray() (which can be found out
> by reflection), the root AbstractCollection.toArray() is not behaving fine
> there.
>
> For harmony the fix would be to correct this issue "correctly" by changing
> the base AbstractCollection implementation (I would recommend that).
>
> This is also the root cause for HARMONY-6236 and similar issues, the fix
> there is invalid, but I cannot reopen the issue.
>
>  was:
> If you call ConcurrentHashMap.keySet().toArray() [as done in trunks
> Lucene's RAMDirectory#fileMap] and another thread modifies the collecton,
> you get NoSuchElementExceptions or AIOOBEs. The reason is that
> AbstractCollection.toArray methods allocate the array using the current size
> of the collection and then either iterate on the values (which is oficially
> supported by ConcurrentHashMap, its iterator is safe for concurrent
> modification!) and set them on the target without checking bounds. On the
> other hand if there are too few entries in the collection, the array is
> nulled at the end. The bad thing is that the toArray() and toArray(T[])
> methods behave differently, so depending on the modification they throw
> different exceptions (one impl simply drops entries that dont fit into the
> array).
>
> Since Java SE 6, its officially documented, how toArray must behave: [
> http://download.oracle.com/javase/6/docs/api/java/util/AbstractCollection.html#toArray(T[])<http://download.oracle.com/javase/6/docs/api/java/util/AbstractCollection.html#toArray%28T[]%29>];
> This is violated by harmony and even the fix in HARMONY-6419 does not
> respect it, leading to such bugs.
>
> Java SE 5 does not document that, but ConcurrentHashMap.keySet(), values()
> and entrySet() have own implementations of toArray() (which can be found out
> by reflection), the root AbstractCollection.toArray() is not behaving fine
> there.
>
> For harmony the fix would be to correct this issue "correctly" by changing
> the base AbstractCollection implementation (I would recommend that).
>
> This is also the root cause for HARMONY-6419 and similar issues, the fix
> there is invalid, but I cannot reopen the issue.
>
>
> > AbstractCollection.toArray() and AbstractCollection.toArray(T[]) are
> broken for concurrently modified collections like ConcurrentHashMap.keySet()
> >
> -------------------------------------------------------------------------------------------------------------------------------------------------
> >
> >                 Key: HARMONY-6681
> >                 URL: https://issues.apache.org/jira/browse/HARMONY-6681
> >             Project: Harmony
> >          Issue Type: Bug
> >          Components: Classlib
> >    Affects Versions: 6.0M4, 5.0M16
> >            Reporter: Uwe Schindler
> >
> > If you call ConcurrentHashMap.keySet().toArray() [as done in trunks
> Lucene's RAMDirectory#fileMap] and another thread modifies the collecton,
> you get NoSuchElementExceptions or AIOOBEs. The reason is that
> AbstractCollection.toArray methods allocate the array using the current size
> of the collection and then either iterate on the values (which is oficially
> supported by ConcurrentHashMap, its iterator is safe for concurrent
> modification!) and set them on the target without checking bounds. On the
> other hand if there are too few entries in the collection, the array is
> nulled at the end. The bad thing is that the toArray() and toArray(T[])
> methods behave differently, so depending on the modification they throw
> different exceptions (one impl simply drops entries that dont fit into the
> array).
> > Since Java SE 6, its officially documented, how toArray must behave: [
> http://download.oracle.com/javase/6/docs/api/java/util/AbstractCollection.html#toArray(T[])<http://download.oracle.com/javase/6/docs/api/java/util/AbstractCollection.html#toArray%28T[]%29>];
> This is violated by harmony and even the fix in HARMONY-6236 does not
> respect it, leading to such bugs.
> > Java SE 5 does not document that, but ConcurrentHashMap.keySet(),
> values() and entrySet() have own implementations of toArray() (which can be
> found out by reflection), the root AbstractCollection.toArray() is not
> behaving fine there.
> > For harmony the fix would be to correct this issue "correctly" by
> changing the base AbstractCollection implementation (I would recommend
> that).
> > This is also the root cause for HARMONY-6236 and similar issues, the fix
> there is invalid, but I cannot reopen the issue.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>

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