PreviousNextTracker indexSee it online !

(127/240) 3728 - UndoManager assertion error on paste

My file got malformed. This is the second problem related to undo. Please take some steps to remove them. Recent changes (optimizations) in undo are suspected. Using current trunk version r21791 of jedit became risky.

I will try to reproduce, but had to paste the log and give a warning immediately.

8:18:49 AM \[main\] \[message\] Log: java.version=1.6.0_24
8:18:49 AM \[main\] \[message\] Log: java.vm.version=19.1-b02
8:18:49 AM \[main\] \[message\] Log: java.vm.name=Java HotSpot(TM) Client VM
8:18:49 AM \[main\] \[message\] Log: java.runtime.version=1.6.0_24-b07
8:18:49 AM \[main\] \[message\] Log: java.runtime.name=Java(TM) SE Runtime Environment
8:18:49 AM \[main\] \[message\] Log: java.vendor=Sun Microsystems Inc.
8:18:49 AM \[main\] \[message\] Log: java.compiler=null
8:18:49 AM \[main\] \[message\] Log: os.name=Linux
8:18:49 AM \[main\] \[message\] Log: os.version=2.6.32-5-686
8:18:49 AM \[main\] \[message\] Log: os.arch=i386


11:13:37 AM \[AWT-EventQueue-0\] \[error\] BeanShellAction: java.lang.AssertionError
11:13:37 AM \[AWT-EventQueue-0\] \[error\] BeanShellAction: at org.gjt.sp.jedit.buffer.UndoManager.getReplaceFromRemoveInsert(UndoManager.java:370)
11:13:37 AM \[AWT-EventQueue-0\] \[error\] BeanShellAction: at org.gjt.sp.jedit.buffer.UndoManager.access$500(UndoManager.java:41)
11:13:37 AM \[AWT-EventQueue-0\] \[error\] BeanShellAction: at org.gjt.sp.jedit.buffer.UndoManager$CompoundEdit.add(UndoManager.java:624)
11:13:37 AM \[AWT-EventQueue-0\] \[error\] BeanShellAction: at org.gjt.sp.jedit.buffer.UndoManager.contentInserted(UndoManager.java:195)
11:13:37 AM \[AWT-EventQueue-0\] \[error\] BeanShellAction: at org.gjt.sp.jedit.buffer.JEditBuffer.insert(JEditBuffer.java:736)
11:13:37 AM \[AWT-EventQueue-0\] \[error\] BeanShellAction: at org.gjt.sp.jedit.buffer.JEditBuffer.insert(JEditBuffer.java:684)
11:13:37 AM \[AWT-EventQueue-0\] \[error\] BeanShellAction: at org.gjt.sp.jedit.textarea.Selection$Range.setText(Selection.java:275)
11:13:37 AM \[AWT-EventQueue-0\] \[error\] BeanShellAction: at org.gjt.sp.jedit.textarea.TextArea.replaceSelection(TextArea.java:2081)
11:13:37 AM \[AWT-EventQueue-0\] \[error\] BeanShellAction: at org.gjt.sp.jedit.textarea.JEditTextArea.replaceSelection(JEditTextArea.java:248)
11:13:37 AM \[AWT-EventQueue-0\] \[error\] BeanShellAction: at org.gjt.sp.jedit.Registers._paste(Registers.java:387)
11:13:37 AM \[AWT-EventQueue-0\] \[error\] BeanShellAction: at org.gjt.sp.jedit.Registers.paste(Registers.java:276)

Submitted jarekczek - 2012-08-05 09:22:41 Assigned thomasmey
Priority 5 Labels
Status pending Group None
Resolution fixed

Comments

2012-08-09 15:47:14
k_satoda

The failing assertion is:
> /\* search for nothing (via regexp) will results just in Insert-Edits.
> \* So we won't get here as lastElement will be an Insert, too
> \*/
> assert newElement \!= undoClearDirty;
http://jedit.svn.sourceforge.net/viewvc/jedit/jEdit/trunk/org/gjt/sp/jedit/buffer/UndoManager.java?revision=21939&view=markup#l367

Re-reading the comments on assertions including the above, I'm being
tempted to replace all assertions into the 2x2 tests. I know some of
the tests are redundant, but it seems hard to be \*sure\* of that.

Additionally, if these assertions are based on some conditions of
caller sites, such conditions may be broken by future changes without
knowing the existence of these assertions.

The advantage of assertions seems only little performance gain here
because a branch (returning null) is already there for a similar case.

However, I want to be sure how the assumption in the comment was broken.
The analysis is in progress.

2012-08-09 20:24:42
jarekczek

- **priority**: 8 --> 5

2012-08-09 20:24:42
jarekczek

It was only once when I got it. I know I made a double paste, while usually I use "Duplicate lines" shortcut for that. I had several lines in clipboard. Probably previous activity plays role here. It was not a fresh instance of jedit, I did about hour of work before getting there. I know this is of little help, but that's all I can give at the moment. After all it's only an assertion, so maybe a usual priority of 5 would be enough. The other s&r ticket contains steps to reproduce.

2012-08-10 09:21:54
thomasmey

Mhh. I'll try to reproduce this one. But I guess this is an consecutive error of bug 3551910.

2012-08-16 14:38:57
jarekczek

After I got it again, despite the patch, I took a look at the code. Thank you for detailed comments, they help a lot in such situations. I wonder if the writer had in mind that this code will also be reached after regular edits and macros, not only after search & replace. But that's a side note only.

The problem must be in the "Never mark buffers dirty if contents are unchanged" switch (in Saving & Backup section), that I had on only on one of my machines. The only one that threw the assertion. That switch, if on, makes the dirty flag clear after any edit that restores the file to its original state.

2012-08-16 16:16:53
jarekczek

And finally steps to reproduce:
1. java -ea -jar jedit.jar -noplugins -nosettings
2. check Never mark buffers dirty if contents are unchanged
3. type something
4. create new buffer (untitled-2), this makes the new setting effective
5. change the mode to c
6. type enter (newline and indent)
7. select all (only newline, ok)
8. type anything, say "a", it is thrown silently. If you paste something instead, you will get a loud assertion break

2012-08-16 20:49:27
thomasmey

"After I got it again, despite the patch, I took a look at the code. Thank
you for detailed comments, they help a lot in such situations. I wonder if
the writer had in mind that this code will also be reached after regular
edits and macros, not only after search & replace. But that's a side note
only." -> yes, he had :-)

Okay, the assumption was incorrect. with the "useMD5forDirtyCalculation" option set, the "newElement" can be significant for undo.

Attached patch fixes this.

But there seems to be another bug with the dirty flag in your test case. while redo all changes the dirty flag is not set correctly. This is maybe an already existing bug. I need to check this.

2012-08-16 20:50:40
thomasmey

v1

Dont-compact-significant-Edits.patch (1.0Kio)

2012-08-21 08:12:04
thomasmey

"But there seems to be another bug with the dirty flag in your test case:"

1.) Create new file/empty buffer
2.) Enter "enter"
3.) Enter "tab"
4.) Select all text
5.) Enter "a"
6.) Undo all changes
7.) Redo the first change -> dirty flag will not get set\!

"This is maybe an already existing bug. I need to check this."
-> Yes, indeed it is. This bug already exits in 4.5.2

2012-09-06 15:12:34
ezust

- **assigned_to**: k_satoda --> thomasmey

2012-09-06 15:13:19
ezust

Committed 22171.

2012-09-06 15:13:19
ezust

- **status**: open --> pending-fixed