Community
Participate
Working Groups
In the most cases occured at PC with high display resolution(>=1600x1200). It can be reproduced at (1280x1024) resolution. TableViewer should to display at least MIN_FLUSHLENGTH(64) on the screen. I have table viewer with DeferedContentProvider. The table viewer contains MIN_FLUSHLENGTH or more visible elements on the screen. If I try to update MIN_FLUSHLENGTH elements ArrayIndexOutOfBoundsException occured at point (2). // class ConcurrentTableUpdator org.eclipse.jface.viewers.deferred.ConcurrentTableUpdator [...] // (1) in case if lastClear == this.MIN_FLUSHLENGTH // see (2) // if (lastClear >= pendingClears.length) { int newCapacity = Math.min(MIN_FLUSHLENGTH, lastClear * 2); int[] newPendingClears = new int[newCapacity]; System.arraycopy(pendingClears, 0, newPendingClears, 0, lastClear); pendingClears = newPendingClears; } // (2) exception occured here // coz pendingClears.length stay unchanged pendingClears[lastClear++] = toClear; [...] If you need aditional info about bug, let's me know. Reproduced in Eclipse v3.1x & v3.2x BTW, Why do you use int[] arrays instead of ArrayList?
Pavel, could you provide a patch for this?
> Pavel, could you provide a patch for this? > something like that: in line >int newCapacity = Math.min(MIN_FLUSHLENGTH, lastClear * 2); change to int newCapacity = lastClear * 2; // or = lastClear + 1 in any case later in ConcurrentTableUpdator.updateTable() pendingClears array allocated with size MIN_FLUSHLENGTH again Did you try to reproduce that bug?
(In reply to comment #2) > Did you try to reproduce that bug? No, but if you could write a small test case or snippet that demonstrates the problem that would be great. :)
(In reply to comment #3) > > Did you try to reproduce that bug? > > No, but if you could write a small test case or snippet that demonstrates the > problem that would be great. :) > maybe later. I can't promise anything now. When are you planning to fix that bug? ;)
The new codes works different and this bug is very old, this bug should be reviewed it can be reproduced.
The bug also occurs using eclipse RAP, that uses exactly this code. simply applying your suggested patch (int newCapacity = lastClear * 2;) fixed this issue. See discussion: http://www.eclipse.org/newsportal/article.php?id=6329&group=eclipse.technology.rap
Will there ever be anything done on this one? This bug is open for ages...
(In reply to comment #7) > Will there ever be anything done on this one? > This bug is open for ages... I have asked for a test case but nobody cared to attach one. I am hesitant to just change the code without proof that the fix improves the situation.
Hi Boris, I can not provide a standalone test-case, it would have been for eclipse RAP anyway, since I noticed the bug there, too. But I can verify that the fix improves the situation. I know this might not satisfy you, but I hope you implement the fix anyway. Regards, Markus
Hitesh is now responsible for watching bugs in the [Viewers] component area.
Suggest deprecating and deleting the virtual table/tree viewer support instead of trying to fix this stuff. There are other custom tables and trees out there that do a much better job of handling virtual elements. This one is barely used and doesn't work well.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
