Sometimes (usually after a bit of uptime using jEdit intensively) when I save a buffer, everything in the main TextArea goes wild. That is to say the display is broken and random stuff is displayed in place of the buffer I'm currently editing.
It first scared the hell out of me (thinking my buffer was corrupted) but only the display is. If I save again, the corruption changes (other random stuff is displayed - sometimes it goes back to normal) and if I scroll down (pagedown/up) or change buffer everything is back to normal. So all in all, jEdit is still usable.
Note that the syntax highlighting is unaffected by this bug. So I see garbage with the correct syntax highlighting of the buffer underneath. It is sometimes quite ... artistic ;)
Let me know if you need any more details or if I should try something while the display is messed up to help investigation.
Sorry if it's a dupe. I can't believe I'm the only one seeing that but I couldn't find this bug in the tracker...
[message] Log: java.version=1.6.0
[message] Log: java.vm.version=1.6.0-b105
[message] Log: java.runtime.version=1.6.0-b105
[message] Log: java.vendor=Sun Microsystems Inc.
[message] Log: java.compiler=null
[message] Log: os.name=Linux
[message] Log: os.version=2.6.17-10-generic
[message] Log: os.arch=i386
[message] Log: user.home=/home/pieroxy
[message] Log: java.home=/home/pieroxy/progs/jdk1.6.0/jre
[message] Log: java.class.path=/home/pieroxy/progs/jedit/jedit.jar
[notice] jEdit: jEdit version 4.3pre8
Logged In: YES
user_id=75113
Originator: NO
This has been seen by many people, but no one can easily duplicate it... it doesn't seem to follow any pattern to be triggered. Interesting bug, though, and pretty annoying.
Logged In: YES
user_id=1630383
Originator: NO
I can see this bug too - in 4.3pre7, pre8 and pre9. However, I haven't been able to figure out when it happens, it seems random to me. The effect is that certain lines in the display appear as duplicated while others disappear, it looks like some portion of the display is shifted vertically and when I move the cursor up and down, the lines seem to be repainted properly. Minimizing and restoring jedit corrects the problem. Fortunately the buffer is not corrupted, just the display.
Logged In: YES
user_id=396194
Originator: NO
Though I can't reproduce this, I suspect it's caused by SideKick. I've only seen it in Java files, so it may be JavaSideKick. The last two times it's happened, I was able to get it to happen repeatedly when saving a file. The first time, when I disabled SideKick, it stopped. Of course stopping SideKick stops ALL the *SideKick plugins, so the next time, I just diabled JavaSideKick and that also stopped the display corruption. FWIW, after I re-enable the plugins the problems does NOT come back.
Not sure what all this means, but I'd like to hear from others what TYPES of files this happens to and whether or not they have SideKick installed and set to parse on Save.
Jeff
Logged In: YES
user_id=130366
Originator: NO
I only encounter this bug with the XML plugin enabled. If I disable it, the problem goes away. I'm seeing it currently on an ubuntu dapper and feisty system with jedit 4.3pre10 using Java 1.6.0_01
Logged In: YES
user_id=935841
Originator: NO
When this happens, I think that the line count, or the position of the caret is incorrect. You'll notice this if yo try to scroll to the bottom of the document.
currently, when it happens to me, I split and unsplit the editpane. The resultant editpane looks fine after that.
I can't reproduce this reliably either.
Logged In: YES
user_id=935841
Originator: NO
Anyway, until someone attaches a testcase that can reproduce this bug, we can't fix it. by testcase, I mean:
a file that you were editing and that can cause this bug when you save it.
description of what plugins you have installed
your properties when you experienced this. (in particualr, edit mode, sidekick, and folding settings). Until we get something like that, this bug report is considered "incomplete".
Logged In: YES
user_id=130366
Originator: NO
Screenshot: http://www.commoner.com/lsimon/jedit-textarea.png (sorry I can't send the file)
Properties: http://www.commoner.com/lsimon/jedit.properties
Sorry I don't have more of a testcase. I'll send a file that it happens in soon.
In my case these are CSS and HTML files where I experience this, and right after Ctrl-S.
Logged In: YES
user_id=1230915
Originator: NO
I have this problem too. Windows XP SP2 2GB Java JRE 6.2 and dual monitor.
I tested, if it is a problem of my other software installed on my computer. So I
made a new fresh install of W XP (no dual monitor drivers!), JRE 6.2, jEdit
4.3.10 with XML-plugin (and the others for this plugin), nothing more except a
firewall... No special changes for jEdit.
Same error!
I open a file with the ending .php - eg. test.php, in it some HTML code and in
the header some CSS formates, say to the sidekick to check it like HTML and on
save bad text display.
No problems with 4.2 :-)
Logged In: YES
user_id=285591
Originator: NO
Hi, it happens to me now. Often it's when I create some explicit folds and close them. I use the latest 4.3pre12 trunk with that exception
14:08:11 [error] ExtensionManager: Error repainting line range {0,28}:
14:08:11 [error] ExtensionManager: java.lang.ArrayIndexOutOfBoundsException: -31
14:08:11 [error] ExtensionManager: at org.gjt.sp.jedit.syntax.DisplayTokenHandler.canMerge(DisplayTokenHandler.java:240)
14:08:11 [error] ExtensionManager: at org.gjt.sp.jedit.syntax.DisplayTokenHandler.merge(DisplayTokenHandler.java:207)
14:08:11 [error] ExtensionManager: at org.gjt.sp.jedit.syntax.DisplayTokenHandler.handleToken(DisplayTokenHandler.java:108)
14:08:11 [error] ExtensionManager: at org.gjt.sp.jedit.syntax.TokenMarker.markTokens(TokenMarker.java:250)
14:08:11 [error] ExtensionManager: at org.gjt.sp.jedit.buffer.JEditBuffer.markTokens(JEditBuffer.java:1242)
14:08:11 [error] ExtensionManager: at org.gjt.sp.jedit.textarea.ChunkCache.lineToChunkList(ChunkCache.java:782)
14:08:11 [error] ExtensionManager: at org.gjt.sp.jedit.textarea.ChunkCache.updateChunksUpTo(ChunkCache.java:659)
14:08:11 [error] ExtensionManager: at org.gjt.sp.jedit.textarea.ChunkCache.getLineInfo(ChunkCache.java:256)
14:08:11 [error] ExtensionManager: at org.gjt.sp.jedit.textarea.ExtensionManager.paintScreenLineRange(ExtensionManager.java:102)
14:08:11 [error] ExtensionManager: at org.gjt.sp.jedit.textarea.Gutter.paintComponent(Gutter.java:130)
14:08:11 [error] ExtensionManager: at javax.swing.JComponent.paint(JComponent.java:1027)
14:08:11 [error] ExtensionManager: at javax.swing.JComponent.paintChildren(JComponent.java:864)
14:08:11 [error] ExtensionManager: at javax.swing.JComponent.paint(JComponent.java:1036)
14:08:11 [error] ExtensionManager: at javax.swing.JComponent.paintChildren(JComponent.java:864)
14:08:11 [error] ExtensionManager: at javax.swing.JComponent.paint(JComponent.java:1036)
14:08:11 [error] ExtensionManager: at javax.swing.JComponent.paintChildren(JComponent.java:864)
14:08:11 [error] ExtensionManager: at javax.swing.JComponent.paint(JComponent.java:1036)
14:08:11 [error] ExtensionManager: at javax.swing.JComponent.paintToOffscreen(JComponent.java:5122)
14:08:11 [error] ExtensionManager: at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1382)
14:08:11 [error] ExtensionManager: at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1313)
14:08:11 [error] ExtensionManager: at javax.swing.RepaintManager.paint(RepaintManager.java:1128)
14:08:11 [error] ExtensionManager: at javax.swing.JComponent._paintImmediately(JComponent.java:5070)
14:08:11 [error] ExtensionManager: at javax.swing.JComponent.paintImmediately(JComponent.java:4880)
14:08:11 [error] ExtensionManager: at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:723)
14:08:11 [error] ExtensionManager: at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:679)
14:08:11 [error] ExtensionManager: at javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:659)
14:08:11 [error] ExtensionManager: at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:128)
14:08:11 [error] ExtensionManager: at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
14:08:11 [error] ExtensionManager: at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
14:08:11 [error] ExtensionManager: at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
14:08:11 [error] ExtensionManager: at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
14:08:11 [error] ExtensionManager: at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
14:08:11 [error] ExtensionManager: at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
14:08:11 [error] ExtensionManager: at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
14:08:11 [error] ExtensionManager: at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
Logged In: YES
user_id=187628
Originator: NO
I can reproduce this regularly by moving the bar separating the main text area and the bottom docking area and then saving. By "often", I mean I can see the error about 1 out of 5 adjustments to the bar. I've attached a patch that seems to fix the problem. I say "seems" because my test isn't that reliable, but since I've applied the patch, I have not (yet) seen the error happen again. The patch was generated against revision 11636 of org.gjt.sp.jedit.textarea.FastRepaintManager.java.
File Added: FastRepaintManger.java.diff
Logged In: YES
user_id=187628
Originator: NO
I've attached a patch for the error reported by kpouer below. The patch is against org.gjt.sp.jedit.syntax.DisplayTokenHandler.java at revision 11638. The patch just adds some bounds checking for the arrays.
File Added: DisplayTokenHandler.java.diff
patch to fix ArrayOOB exception reported by kpouer
Logged In: YES
user_id=187628
Originator: NO
I should have mentioned that while the last patch I added takes care of the ArrayOOB exception, I still have not seen this problem since I applied the first patch to my local copy of jEdit. I have never seen the problem with the ArrayOOB exception, but adding index checking is still a good thing.
Logged In: YES
user_id=187628
Originator: NO
The patch I added named "FastRepaintManger.java.diff" does not totally fix the problem. I saw the problem today, just once.
Logged In: YES
user_id=187628
Originator: NO
Yet another possible fix:
In org.gjt.sp.jedit.textarea.ChunkCache.java, replace the getLineInfo(int) method with this version:
LineInfo getLineInfo(int screenLine)
{
try {
updateChunksUpTo(screenLine);
return lineInfo[screenLine];
}
catch(Exception e) {
LineInfo li = new LineInfo();
li.physicalLine = -1;
return li;
}
} //}}}
It seems to me the problem is caused by a 1-off error in either ExtensionManager or ChunkCache, one of them is counting the number of visible lines incorrectly. The problem seems to happen when the last line is not fully visible, that is, there is some fraction of the last line visible, but not all of it. I think ExtensionManager is counting that last partial line and ChunkCache is not, so an ArrayIndexOutOfBounds exception gets thrown and isn't handled correctly. This is all speculation so far. The code in ChunkCache in particular is fairly inscrutable, which is noted in the code:
private void updateChunksUpTo(int lastScreenLine)
{
// this method is a nightmare
if(lastScreenLine >= lineInfo.length)
throw new ArrayIndexOutOfBoundsException(lastScreenLine);
I believe this is exactly where the problem is evidenced, and is due to "lastScreenLine" as calculated by ExtensionManager being 1 greater than that calculated by ChunkCache.
Logged In: YES
user_id=187628
Originator: NO
Deleting the FastRepaintManger.java.diff patch, it should not be applied.
patch to fix this bug
Logged In: YES
user_id=187628
Originator: NO
Attached patch for org.gjt.sp.jedit.textarea.TextArea.java, created against revision 11778. This patch corrects the off-by-one error. I believe this is the fix for this bug.
File Added: TextArea.java.diff
Logged In: YES
user_id=1230915
Originator: NO
Test with jEdit 4.3pre14 (the same with 13,12,11,10...) and XML/Sidekick: TextArea painting corruption when saving
screenshot: http://www.nolink.de/downloads/jedit_bug/screenshot.gif
test file downloadable: http://www.nolink.de/downloads/?id=jedit_bug
Logged In: YES
user_id=663176
Originator: NO
lu10010, the .php test file is not downloadable. Please attach it instead here.
daleanson, thank you very much for your investigations. I'll attach your patches as unified diff against SVN trunk.
I've created a jedit.jar from current SVN (pre14) with this patch included, in case you cannot easily build jEdit yourself. Please test, if it fixes this bug: http://codeprobe.de/tmp/jedit-fix-for-1633393.jar
Logged In: YES
user_id=663176
Originator: NO
File Added: 1633393-fix.diff