#3622 ArrayIndexOutOfBoundsException after Project Open
This happened after starting jEdit and opening a project.
Activity log attached.
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 10
at org.gjt.sp.jedit.buffer.JEditBuffer.getLineStartOffset(JEditBuffer.java:361)
at org.gjt.sp.jedit.textarea.ChunkCache.lineToChunkList(ChunkCache.java:784)
at org.gjt.sp.jedit.textarea.ChunkCache.getLineSubregionCount(ChunkCache.java:272)
at org.gjt.sp.jedit.textarea.DisplayManager.updateScreenLineCount(DisplayManager.java:627)
at org.gjt.sp.jedit.textarea.DisplayManager.getScreenLineCount(DisplayManager.java:230)
at org.gjt.sp.jedit.textarea.DisplayManager.hideLineRange(DisplayManager.java:758)
at org.gjt.sp.jedit.textarea.DisplayManager.expandFolds(DisplayManager.java:404)
at org.gjt.sp.jedit.textarea.DisplayManager.expandFolds(DisplayManager.java:429)
at org.gjt.sp.jedit.textarea.DisplayManager.bufferLoaded(DisplayManager.java:649)
at org.gjt.sp.jedit.textarea.BufferHandler.bufferLoaded(BufferHandler.java:67)
at org.gjt.sp.jedit.buffer.JEditBuffer.fireBufferLoaded(JEditBuffer.java:2609)
at org.gjt.sp.jedit.Buffer.access$700(Buffer.java:91)
at org.gjt.sp.jedit.Buffer$1.run(Buffer.java:289)
at org.gjt.sp.util.WorkThreadPool.doAWTRequest(WorkThreadPool.java:396)
at org.gjt.sp.util.WorkThreadPool.doAWTRequests(WorkThreadPool.java:381)
at org.gjt.sp.util.WorkThreadPool.access$200(WorkThreadPool.java:39)
at org.gjt.sp.util.WorkThreadPool$RunRequestsInAWTThread.run(WorkThreadPool.java:481)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:641)
at java.awt.EventQueue.access$000(EventQueue.java:84)
at java.awt.EventQueue$1.run(EventQueue.java:602)
at java.awt.EventQueue$1.run(EventQueue.java:600)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:611)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
A very similar exception happens after starting jEdit and jumping to the end of the current buffer (Ctrl+End), when PV is active (with the option to remember open project files).
It doesn't reproduce each time. I doubt this has anything to do with PV - from some debugging it turns out that the chunk cache is somehow not in sync with the line manager. PV just seems to make this bug in the core visible.
I think I have a way to reproduce it now:
For me, it happens every time I open a project with 3 .java files that need to be restored from the previous time.
I use as a testcase, jEdit trunk as my test project.
Open 3 java files, change to another project, and change back to this one. I get those exceptions every time.
It's not just at startup.
I encountered this exception. And analyzed it a bit.
In DisplayManager.updateScreenLineCount(), it uses textArea.chunkCache
to get subregion count for a line. But when the active buffer is
switched in textArea while loading a buffer,
DisplayManager.bufferLoaded() will be called after the switch, and the
chunkCache is already switched (by a call of setBuffer() in
TextArea#setBuffer() ) to the new buffer shown in the textArea. Here is
the problem.
It may be solved by defering expandFolds() until the DisplayManager
become active and textArea.chunkCache is available for the correct
buffer.
svn diff for jEdit/trunk r21234
Here is a less environment dependant reproduction recipe:
- Start jEdit with -nosettings
- Open [Global Options] > [Editing].
- Set wrap mode of <global defaults> to "soft".
- Drag&Drop jEdit.java and View.java into the edit pane at once.
I crafted a possible fix (attached) which passes the above recipe. Now
testing in the wild for a while.
Fixed in r21253-21254.