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:41z | Assigned | thomasmey |
---|---|---|---|
Priority | 5 | Category | None |
Status | Pending | Group | None |
Resolution | Fixed | Visibility | No |
2012-08-09 - 15:47:14z 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:42z 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:54z 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:57z 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:53z 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:27z 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-21 - 08:12:04z 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:13:19z ezust |
Committed 22171. |
2012-08-16 - 20:50:40z thomasmey |
Dont-compact-significant-Edits.patch v1 |
---|