Home » Eclipse Projects » Remote Application Platform (RAP) » ArrayIndexOutOfBoundsException in ConcurrentTableUpdator
ArrayIndexOutOfBoundsException in ConcurrentTableUpdator [message #131401] |
Tue, 05 May 2009 11:54 |
Markus rüger Messages: 369 Registered: July 2009 |
Senior Member |
|
|
Hello,
I am using a virtual table with a deffered content provider, a sorter and a
filter. Now, sometimes I get an endless loop because of an
ArrayIndexOutOfBoundsException (for index 64).
The bad thing is that it does not occur always. The good thing is, that I
might know what causes the problem.
In ConcurrentTableUpdater there is a method pushClear(int toClear). There is
a variable "lastClear" which is somtimes ">=" the length of the array
"pendingClear" (I don't know why though). Looking deeper at the method I
noticed, that there is already a condition that checks it and the the code
"seems" to extend the array to twice the length of "lastClear".
I wrote "seems" in quotation mark because it actually does not extend the
array!
The initial capacity of the array "pendingClear" is MIN_FLUSHLENGTH (64).
Now, within the condition the new capacity is calculated using
Math.min(MIN_FLUSHLENGTH, lastClear * 2). So if "lastClear" is bigger than
or equal to the length of the array "pendingClear" it will not extend it,
since AGAIN the capacity is set to MIN_FLUSHLENGTH since Math.min() is used!
That does not make sense in my eyes. I would expect, that the size of the
array is extended in this condition, because other wise the line
pendingClears[lastClear++] = toClear will throw an
ArrayIndexOutOfBoundsException.
Using Math.max() solves the problem and no ArrayIndexOutOfBoundsException
will occur anymore.
I don't know why this condition is made if actually the array will never be
extended.
I check with RCP jface code which is equal to RAP code, but again, the array
will never be extended. Maybe this is a bug in RCP, too.
Regards,
Markus
|
|
| |
Re: ArrayIndexOutOfBoundsException in ConcurrentTableUpdator [message #131558 is a reply to message #131401] |
Wed, 06 May 2009 10:14 |
Rüdiger Herrmann Messages: 581 Registered: July 2009 |
Senior Member |
|
|
Markus,
it looks like a bug. If you want to file a bugzilla, please check
whether this is an issue in RCP or RAP and choose the component
accordingly.
Cheers,
Rüdiger
Markus Krüger wrote:
> Hello,
> I am using a virtual table with a deffered content provider, a sorter and a
> filter. Now, sometimes I get an endless loop because of an
> ArrayIndexOutOfBoundsException (for index 64).
> The bad thing is that it does not occur always. The good thing is, that I
> might know what causes the problem.
>
> In ConcurrentTableUpdater there is a method pushClear(int toClear). There is
> a variable "lastClear" which is somtimes ">=" the length of the array
> "pendingClear" (I don't know why though). Looking deeper at the method I
> noticed, that there is already a condition that checks it and the the code
> "seems" to extend the array to twice the length of "lastClear".
> I wrote "seems" in quotation mark because it actually does not extend the
> array!
>
> The initial capacity of the array "pendingClear" is MIN_FLUSHLENGTH (64).
> Now, within the condition the new capacity is calculated using
> Math.min(MIN_FLUSHLENGTH, lastClear * 2). So if "lastClear" is bigger than
> or equal to the length of the array "pendingClear" it will not extend it,
> since AGAIN the capacity is set to MIN_FLUSHLENGTH since Math.min() is used!
> That does not make sense in my eyes. I would expect, that the size of the
> array is extended in this condition, because other wise the line
> pendingClears[lastClear++] = toClear will throw an
> ArrayIndexOutOfBoundsException.
>
> Using Math.max() solves the problem and no ArrayIndexOutOfBoundsException
> will occur anymore.
>
> I don't know why this condition is made if actually the array will never be
> extended.
> I check with RCP jface code which is equal to RAP code, but again, the array
> will never be extended. Maybe this is a bug in RCP, too.
>
> Regards,
> Markus
>
>
|
|
| |
Re: ArrayIndexOutOfBoundsException in ConcurrentTableUpdator [message #131643 is a reply to message #131633] |
Wed, 06 May 2009 20:03 |
Rüdiger Herrmann Messages: 581 Registered: July 2009 |
Senior Member |
|
|
Markus Krüger wrote:
> I have never reported anything for RCP but as RAP apots its code from RCP I
> assume it is an RCP bug.
Unlikely, but it might be that this is already fixed in RCP, that's
why I asked you to check with RCP.
> Anyway would you ever fix this before it would eb fixed in RCP, or do you
> have to wait for them to change?
We would prefer to have it first fixed in RCP because they know best
their code, have all the test suites. We just adopt it and make it
multi-user.
> Since it is an easy bug, and just one line of code to change, isn't there a
> short way you can go to have this fixed in RCP and RAP very soon?
We would need a bug plus a patch in any case. I would suggest to
open the bug against RCP. If you report the bug id here, we will
monitor it and adopt the changes for RAP when they are blessed by
the RCP guys.
>
> Regards,
> Markus
>
> "Rüdiger Herrmann" <rherrmann@eclipsesource.com> schrieb im Newsbeitrag
> news:gtrnua$2v8$1@build.eclipse.org...
>> Markus,
>>
>> it looks like a bug. If you want to file a bugzilla, please check whether
>> this is an issue in RCP or RAP and choose the component accordingly.
>>
>> Cheers,
>> Rüdiger
>>
>> Markus Krüger wrote:
>>> Hello,
>>> I am using a virtual table with a deffered content provider, a sorter and
>>> a filter. Now, sometimes I get an endless loop because of an
>>> ArrayIndexOutOfBoundsException (for index 64).
>>> The bad thing is that it does not occur always. The good thing is, that I
>>> might know what causes the problem.
>>>
>>> In ConcurrentTableUpdater there is a method pushClear(int toClear). There
>>> is a variable "lastClear" which is somtimes ">=" the length of the array
>>> "pendingClear" (I don't know why though). Looking deeper at the method I
>>> noticed, that there is already a condition that checks it and the the
>>> code "seems" to extend the array to twice the length of "lastClear".
>>> I wrote "seems" in quotation mark because it actually does not extend the
>>> array!
>>>
>>> The initial capacity of the array "pendingClear" is MIN_FLUSHLENGTH (64).
>>> Now, within the condition the new capacity is calculated using
>>> Math.min(MIN_FLUSHLENGTH, lastClear * 2). So if "lastClear" is bigger
>>> than or equal to the length of the array "pendingClear" it will not
>>> extend it, since AGAIN the capacity is set to MIN_FLUSHLENGTH since
>>> Math.min() is used! That does not make sense in my eyes. I would expect,
>>> that the size of the array is extended in this condition, because other
>>> wise the line pendingClears[lastClear++] = toClear will throw an
>>> ArrayIndexOutOfBoundsException.
>>>
>>> Using Math.max() solves the problem and no ArrayIndexOutOfBoundsException
>>> will occur anymore.
>>>
>>> I don't know why this condition is made if actually the array will never
>>> be extended.
>>> I check with RCP jface code which is equal to RAP code, but again, the
>>> array will never be extended. Maybe this is a bug in RCP, too.
>>>
>>> Regards,
>>> Markus
>
>
|
|
| |
Re: ArrayIndexOutOfBoundsException in ConcurrentTableUpdator [message #132631 is a reply to message #132346] |
Wed, 13 May 2009 11:28 |
Markus rüger Messages: 369 Registered: July 2009 |
Senior Member |
|
|
Hi Ivan
yes, it is exactly the same issue!
Regards,
Markus
"Ivan Furnadjiev" <ivan@eclipsesource.com> schrieb im Newsbeitrag
news:gubnrr$jrk$1@build.eclipse.org...
> Markus,
>
> please verify that your case is the same like in this bug:
>
> [Viewers] ArrayIndexOutOfBoundsException exception in
> ConcurrentTableUpdator (used in DeferredContentProvider)
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=165637
>
> Best,
> Ivan
>
> "Markus Kr??????????????????????" wrote:
>> I have never reported anything for RCP but as RAP apots its code from RCP
>> I assume it is an RCP bug.
>> Anyway would you ever fix this before it would eb fixed in RCP, or do you
>> have to wait for them to change?
>> Since it is an easy bug, and just one line of code to change, isn't there
>> a short way you can go to have this fixed in RCP and RAP very soon?
>>
>> Regards,
>> Markus
>>
>> "R?diger Herrmann" <rherrmann@eclipsesource.com> schrieb im Newsbeitrag
>> news:gtrnua$2v8$1@build.eclipse.org...
>>
>>> Markus,
>>>
>>> it looks like a bug. If you want to file a bugzilla, please check
>>> whether this is an issue in RCP or RAP and choose the component
>>> accordingly.
>>>
>>> Cheers,
>>> R?diger
>>>
>>> Markus Kr?ger wrote:
>>>
>>>> Hello,
>>>> I am using a virtual table with a deffered content provider, a sorter
>>>> and a filter. Now, sometimes I get an endless loop because of an
>>>> ArrayIndexOutOfBoundsException (for index 64).
>>>> The bad thing is that it does not occur always. The good thing is, that
>>>> I might know what causes the problem.
>>>>
>>>> In ConcurrentTableUpdater there is a method pushClear(int toClear).
>>>> There is a variable "lastClear" which is somtimes ">=" the length of
>>>> the array "pendingClear" (I don't know why though). Looking deeper at
>>>> the method I noticed, that there is already a condition that checks it
>>>> and the the code "seems" to extend the array to twice the length of
>>>> "lastClear".
>>>> I wrote "seems" in quotation mark because it actually does not extend
>>>> the array!
>>>>
>>>> The initial capacity of the array "pendingClear" is MIN_FLUSHLENGTH
>>>> (64). Now, within the condition the new capacity is calculated using
>>>> Math.min(MIN_FLUSHLENGTH, lastClear * 2). So if "lastClear" is bigger
>>>> than or equal to the length of the array "pendingClear" it will not
>>>> extend it, since AGAIN the capacity is set to MIN_FLUSHLENGTH since
>>>> Math.min() is used! That does not make sense in my eyes. I would
>>>> expect, that the size of the array is extended in this condition,
>>>> because other wise the line pendingClears[lastClear++] = toClear will
>>>> throw an ArrayIndexOutOfBoundsException.
>>>>
>>>> Using Math.max() solves the problem and no
>>>> ArrayIndexOutOfBoundsException will occur anymore.
>>>>
>>>> I don't know why this condition is made if actually the array will
>>>> never be extended.
>>>> I check with RCP jface code which is equal to RAP code, but again, the
>>>> array will never be extended. Maybe this is a bug in RCP, too.
>>>>
>>>> Regards,
>>>> Markus
>>
>>
>>
|
|
| |
Goto Forum:
Current Time: Thu Apr 18 22:58:11 GMT 2024
Powered by FUDForum. Page generated in 0.02287 seconds
|