#3492 Exception while saving a buffer

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.

[Kazutoshi 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.

[Kazutoshi 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 .

[Anonymous]

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?

[Anonymous]

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?

[Matthieu Casanova]

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.

[Kazutoshi 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 .

[Eric Le Lay]

The readLock has been restored in [r22183], so the exception can't hapen anymore
A feature request could be created to request the readlock to be given up by AutosaveRequest as suggested, but we have no solution for this right now.