#3728 UndoManager assertion error on paste

pending-fixed
Thomas Meyer
None
5
2012-09-06
2012-08-05
Jarek Czekalski
No

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)

Discussion

1 2 > >> (Page 1 of 2)
  • 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.

     
    • priority: 8 --> 5
     
  • 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.

     
  • Thomas Meyer
    Thomas Meyer
    2012-08-10

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

     
  • 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.

     
  • 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

     
  • Thomas Meyer
    Thomas Meyer
    2012-08-16

    "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.

     
  • Thomas Meyer
    Thomas Meyer
    2012-08-21

    "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

     
  • Alan Ezust
    Alan Ezust
    2012-09-06

    • assigned_to: k_satoda --> thomasmey
     
1 2 > >> (Page 1 of 2)