While saving a buffer, I got the following exception:
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 16431
at org.gjt.sp.jedit.buffer.JEditBuffer.getLineText(JEditBuffer.java:517)
at org.gjt.sp.jedit.buffer.JEditBuffer.getLineText(JEditBuffer.java:499)
at org.gjt.sp.jedit.bufferio.BufferIORequest.write(BufferIORequest.java:364)
at org.gjt.sp.jedit.bufferio.BufferAutosaveRequest.run(BufferAutosaveRequest.java:82)
at org.gjt.sp.util.WorkThread.doRequest(WorkThread.java:216)
at org.gjt.sp.util.WorkThread.doRequests(WorkThread.java:183)
at org.gjt.sp.util.WorkThread.run(WorkThread.java:157)
Additional information: This is a local text file with 16431 lines, which I've been
maintaining for several years now. I don't recall ever having exceptions while saving
it in the past. I frequently perform copy/paste/cut operations on the file, as well
as undo/redo, which might have caused the problem.
| Submitted | shlomy - 2010-12-23 - 06:36:07z | Assigned | kpouer |
|---|---|---|---|
| Priority | 3 | Category | editor core |
| Status | Open | Group | None |
| Resolution | None | Visibility | No |
| 2010-12-23 - 06:58:16z k_satoda |
This happens because BufferAutosaveRequest doesn't lock the buffer while reading it. The exception is thrown when some lines were deleted while BufferAutosaveRequest is running. This means that the auto save file can be corrupted silently, when some lines were added, or edited without changing the number of lines. However, if BufferAutosaveRequest locks the buffer, any modification to the buffer is halt until the save complete; it must be anoying. Thus the locking is not done: commented out from source code. The right solution will be, locking the buffer in BufferAutosaveRequest, and abort the request with the lock if someone request a write lock of the buffer. |
|---|---|
| 2010-12-30 - 08:49:40z k_satoda |
> However, if BufferAutosaveRequest locks the buffer, any modification to > the buffer is halt until the save complete; it must be anoying. Thus the > locking is not done: commented out from source code. FYI, I found the exact revision which did this. http://jedit.svn.sourceforge.net/jedit/?view=rev&rev=4050 Please see the diff of BufferIORequest.java and CHANGES.txt . |
| 2010-12-30 - 09:08:05z shlomy |
I think it's better to do the locking. This change that you found was made more than
8 years ago. Since then, the performance must have changed greatly - both jEdit as
an application, the JRE and the storage. If this lock really annoys users, we can maybe lock parts of a buffer - e.g. separate the buffer to 1MB blocks and protect each one separately. What do you think? |
| 2010-12-30 - 09:08:52z shlomy |
Another thing to note is that I received this shortly after saving a buffer. I find it strange the AutoSave saves the buffer shortly after I manually saved it, no? |
| 2011-01-08 - 10:25:52z kpouer |
I don't think we have a choice here, if we don't do the locking and some modifications
are done on the buffer during the saving operation we could have a saved file that
do not contains the real content of the buffer. It could be possible to lock only the time we copy the buffer content in memory before saving but it would be a problem with big buffers. I don't think it is strange that the exception happened shortly after you saved, the autosave is done every XX seconds, and when you save the timer is not resetted. |
| 2011-01-08 - 17:20:23z k_satoda |
Sorry, I forgot to put the summary of discussion which I moved to jedt-devel. http://old.nabble.com/--jedit-Bugs-3142482---Exception-while-saving-a-buffer-tt30556198.html In short, we agreed that the idea of partial lock doesn't work, and the right solution will be the way in my first comment. For a record, the timer for auto-save is in jedit/Autosave.java . |