[ jEdit-devel ] [ jedit-Bugs-1633393 ] TextArea painting corruption when saving

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Bugs item #1633393, was opened at 2007-01-11 09:09
Message generated for change (Comment added) made by daleanson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1633393&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: text area and syntax packages
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: pieroxy (pieroxy)
Assigned to: Nobody/Anonymous (nobody)
Summary: TextArea painting corruption when saving

Initial Comment:
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

----------------------------------------------------------------------

>Comment By: Dale Anson (daleanson)
Date: 2008-12-21 07:59

Message:
I added a new patch that appears to fix this.  I think my previous patch to
SideKick masks a deeper problem.  This new patch is for JEditBuffer, which
is where I think the root of the problem lies.  

>From email I sent to the jedit-devel list:

"I've spent some more time looking into this, and I think the root problem
is the "seg" field in JEditBuffer.  This field is a Segment, which should
be treated as immutable, but it is not handled that way at all.  Declaring
the Segment as a field and not handling the Segment as an immutable object
means JEditBuffer is not reentrant, so multiple threads accessing the same
Buffer may not get consistent results.  So my "fix" is not a good one, it
does just mask a deeper problem."

----------------------------------------------------------------------

Comment By: Dale Anson (daleanson)
Date: 2008-12-18 14:49

Message:
I attached a diff showing the fix.  The solution is to wrap the call to the
"convert" method in ElementUtils.java in a SwingUtilities.invokeLater
block.  Reading through the code, I'm not sure at all how this can cause
any sort of text area corruption.  There are potentially a lot of calls to
the Buffer object to get line and column positions, so perhaps somehow that
is causing the problem.

----------------------------------------------------------------------

Comment By: Anthony Keeley (keeleyt83)
Date: 2008-12-18 07:14

Message:
It appears to be working. I saw no errors on a file that i had seen errors
on yesterday. I'll comment back in a few days and let you know if worked
for me. Thanks Dale.

----------------------------------------------------------------------

Comment By: Dale Anson (daleanson)
Date: 2008-12-17 17:57

Message:
I believe I have a fix for this.  Please try this version of SideKick:

http://jedit.wiki.sourceforge.net/space/showimage/SideKick.jar

----------------------------------------------------------------------

Comment By: lu10010 (lu10010)
Date: 2008-11-20 01:22

Message:
jEdit 4.3.16 same error! Screenshot:
www.nolink.de/downloads/jedit_bug/error_4_3_16.png
It is not possible to edit HTML/CSS/Javascript/PHP with 4.3.x and the
XML-Plugin...

----------------------------------------------------------------------

Comment By: lu10010 (lu10010)
Date: 2008-09-16 02:44

Message:
jEditCorruptionTestFile.html opened in fresh installed jEdit 4.3 pre 15
Java 1.6.0_17 on a fresh installed WinXP with only XML-Plugin and depending
plugins, switched Sidekick Parser to HTML, saved file (without some "small
changes") 2-3 times and: display error. Sreenshot:
http://www.nolink.de/downloads/jedit_bug/error_03_1.gif (no file-upload on
sf)
AND NO TO THIS: "it seems that the frequency and severity of this bug is
decreasing"

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2008-09-12 13:43

Message:
I tried using that test file but could not reproduce any painting
corruption or array bounds errors.

In fact, I did just today see a painting corruption, while saving a buffer
that was parsed in Outline.
I saw squares. But scrolling to the bottom and then back to the top worked
fine.
No exceptions. So it is not as bad as before. the occasional painting
error that goes away after scrolling up and down is quite less of a bother
for me. 
Anyway, I still don't have a reproducible test case, and it seems that the
frequency and severity of this bug is decreasing.. 

----------------------------------------------------------------------

Comment By: Anthony Keeley (keeleyt83)
Date: 2008-09-08 15:38

Message:
I've got what i think is a reproducible test case in the attached HTML
file. Make sure you open it in HTML mode make a few small changes, and save
again to see the corruption. Please download the file and try it for
yourselves; I would like to hear back from people that were getting this
problem and ones that weren't, so we can verify that this is a good test
case.
File Added: jEditCorruptionTestFile.html

----------------------------------------------------------------------

Comment By: Anthony Keeley (keeleyt83)
Date: 2008-09-04 10:05

Message:
Logged In: YES 
user_id=1883940
Originator: NO

Any progress on this bug? I found something today but not sure if its
worth anything. After getting a buffer to corrupt on a save, i moved the
cursor to a line that was originally empty but now contained garbage text.
Whenever I hit the home key, i got this exception:

java.lang.IllegalArgumentException: caret out of bounds: -110
	at
org.gjt.sp.jedit.textarea.TextArea.moveCaretPosition(TextArea.java:2375)
	at
org.gjt.sp.jedit.textarea.TextArea.moveCaretPosition(TextArea.java:2356)
	at
org.gjt.sp.jedit.textarea.TextArea.moveCaretPosition(TextArea.java:2345)
	at
org.gjt.sp.jedit.textarea.TextArea.goToFirstVisibleLine(TextArea.java:3253)
	at
org.gjt.sp.jedit.textarea.JEditTextArea.smartHome(JEditTextArea.java:94)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.gjt.sp.jedit.bsh.Reflect.invokeMethod(Reflect.java:134)
	at org.gjt.sp.jedit.bsh.Reflect.invokeObjectMethod(Reflect.java:80)
	at org.gjt.sp.jedit.bsh.Name.invokeMethod(Name.java:855)
	at
org.gjt.sp.jedit.bsh.BSHMethodInvocation.eval(BSHMethodInvocation.java:75)
	at
org.gjt.sp.jedit.bsh.BSHPrimaryExpression.eval(BSHPrimaryExpression.java:102)
	at
org.gjt.sp.jedit.bsh.BSHPrimaryExpression.eval(BSHPrimaryExpression.java:47)
	at org.gjt.sp.jedit.bsh.BSHBlock.evalBlock(BSHBlock.java:130)
	at org.gjt.sp.jedit.bsh.BSHBlock.eval(BSHBlock.java:80)
	at org.gjt.sp.jedit.bsh.BshMethod.invokeImpl(BshMethod.java:362)
	at org.gjt.sp.jedit.bsh.BshMethod.invoke(BshMethod.java:258)
	at org.gjt.sp.jedit.bsh.BshMethod.invoke(BshMethod.java:186)
	at
org.gjt.sp.jedit.BeanShellFacade.runCachedBlock(BeanShellFacade.java:222)
	at org.gjt.sp.jedit.BeanShell.runCachedBlock(BeanShell.java:441)
	at org.gjt.sp.jedit.BeanShellAction.invoke(BeanShellAction.java:76)
	at org.gjt.sp.jedit.gui.InputHandler.invokeAction(InputHandler.java:352)
	at org.gjt.sp.jedit.gui.InputHandler.invokeAction(InputHandler.java:317)
	at
org.gjt.sp.jedit.gui.DefaultInputHandler.handleKey(DefaultInputHandler.java:197)
	at
firstmate.FirstMateInputHandler.handleKey(FirstMateInputHandler.java:201)
	at
org.gjt.sp.jedit.input.AbstractInputHandler.processKeyEventKeyStrokeHandling(AbstractInputHandler.java:405)
	at
org.gjt.sp.jedit.gui.InputHandler.processKeyEvent(InputHandler.java:151)
	at
org.gjt.sp.jedit.textarea.TextArea.processKeyEvent(TextArea.java:4696)
	at java.awt.Component.processEvent(Unknown Source)
	at java.awt.Container.processEvent(Unknown Source)
	at java.awt.Component.dispatchEventImpl(Unknown Source)
	at java.awt.Container.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source)
	at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown Source)
	at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown
Source)
	at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown
Source)
	at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source)
	at java.awt.Component.dispatchEventImpl(Unknown Source)
	at java.awt.Container.dispatchEventImpl(Unknown Source)
	at java.awt.Window.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)

----------------------------------------------------------------------

Comment By: geniosity (geniosity)
Date: 2008-08-28 02:51

Message:
Logged In: YES 
user_id=1306600
Originator: NO

I can confirm that I see squares, as well as lines from the top of the
text area being "moved" to somewhere in the middle of the page.

----------------------------------------------------------------------

Comment By: lu10010 (lu10010)
Date: 2008-08-27 02:53

Message:
Logged In: YES 
user_id=1230915
Originator: NO

Screenshots of errors and originals:
http://www.nolink.de/downloads/?id=jedit_bug
 origi_01.gif -> error_01_01.gif ...
 origi_02.gif -> error_02_01.gif ...
error_02_2.gif with a error message like the one I have sent on 2008-08-19
18:04 down below

Some older error screenshots without original shots: 
 jedit4.3.pre15.test.png
 screenshot.gif

----------------------------------------------------------------------

Comment By: Anthony Keeley (keeleyt83)
Date: 2008-08-26 18:57

Message:
Logged In: YES 
user_id=1883940
Originator: NO

I had noticed that it was part of the file, but I don't think it was from
the last line of the file. I will take a look tomorrow at work.

----------------------------------------------------------------------

Comment By: Dale Anson (daleanson)
Date: 2008-08-26 15:19

Message:
Logged In: YES 
user_id=187628
Originator: NO

A question for anyone who has seen this --  

Almost always, I see some text followed by some squares.  I think I've
noticed that the text that is displayed is always the last line of the
file.  Can anyone confirm?

----------------------------------------------------------------------

Comment By: Dale Anson (daleanson)
Date: 2008-08-25 22:41

Message:
Logged In: YES 
user_id=187628
Originator: NO

So it's not the threading via jEdit's Worker classes.  I replaced them in
SideKick with the SwingWorker class, and still see the same problem.  Using
the SwingWorker class does clean up the code a little, but it doesn't fix
this corruption problem afterward.  

----------------------------------------------------------------------

Comment By: Dale Anson (daleanson)
Date: 2008-08-25 06:54

Message:
Logged In: YES 
user_id=187628
Originator: NO

Alan, I suspect your thought that it's a threading issue is probably
right.  I've seen this problem in a number of file types, html, xml, jsp,
and java for sure, all of which have a sidekick parser.  I'm not sure if
I've seen the problem in files that don't have a sidekick parser.  I do
know that the SideKick plugin itself handles the threading by using the
jEdit Worker* classes.  These classes are pretty old, as jEdit code goes. 
I'm wondering if there is a subtle bug in the Worker classes that is
causing this.  I assume you're aware of the SwingWorker classes that were
added to Java 1.6 and are available as a separate library for earlier Java
versions.  SwingWorker has gone through a lot of changes and testing over
the past few years to overcome the various threading issues in Swing. 
Maybe it would be worthwhile to replace the Worker classes with
SwingWorker?

----------------------------------------------------------------------

Comment By: lu10010 (lu10010)
Date: 2008-08-25 02:17

Message:
Logged In: YES 
user_id=1230915
Originator: NO

It would be helpful if the |Options.Plugin.Sidekick.General.Parse on
buffer save|-switch would work: if switched off there should be no parsing!
But the bug is displayed on buffer save if the parser is switched to HTML.

Work around would be a macro for CTRL-S: save actual parser, switch to
parser.none, save buffer, switch back to actual parser. I tried to record a
macro... But java is not my world so I have to stay with jE4.2

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2008-08-24 23:33

Message:
Logged In: YES 
user_id=935841
Originator: NO

I've also seen text area corruption when using sidekick with .java and
.props files (java /property sidekick).
So I think this problem is not specific to the XML plugin. I've only seen
it when I use sidekick, but since I can't reproduce it, I can't really
figure out how to test it further.

----------------------------------------------------------------------

Comment By: Anthony Keeley (keeleyt83)
Date: 2008-08-19 11:44

Message:
Logged In: YES 
user_id=1883940
Originator: NO

My experience seems to also imply its an issue with the XML plugin: it
only seems to happen to me whenever I'm working on JSP or HTML files.
Especially large, malformed ones. I've never had the issue working on java
files, like previous users, but that doesn't mean that similar issues
weren't happening with the java parsing functionality.

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2008-08-19 11:27

Message:
Logged In: YES 
user_id=935841
Originator: NO

I am willing to bet that there is some sort of non thread-safe thing
happening when the XML parser needs to parse on save.
the XML parser by the way, is based on a very old deprecated API, and
should be rewritten to use the more modern standard API offered by Xerces
2.9 (which it is not currently using).

I started on this project a couple of years ago but didn't get far, and
now I don't have time to continue, but you can see the starting point for
this in xml/parser/XercesParserImpl. I wish someone else would pick it up
and update the XML parser. 
Maybe during that porting process, someone can also make it more thread
safe.

----------------------------------------------------------------------

Comment By: lu10010 (lu10010)
Date: 2008-08-19 11:04

Message:
Logged In: YES 
user_id=1230915
Originator: NO

Perhaps this error message can be important for this bug:
this error message comes sometimes in combination with this "TextArea
painting corruption when saving"

ERROR MSG:

java.lang.ArrayIndexOutOfBoundsException: 9508
	at
org.gjt.sp.jedit.syntax.DisplayTokenHandler.canMerge(DisplayTokenHandler.java:240)
	at
org.gjt.sp.jedit.syntax.DisplayTokenHandler.merge(DisplayTokenHandler.java:207)
	at
org.gjt.sp.jedit.syntax.DisplayTokenHandler.handleToken(DisplayTokenHandler.java:108)
	at org.gjt.sp.jedit.syntax.TokenMarker.markTokens(TokenMarker.java:250)
	at org.gjt.sp.jedit.buffer.JEditBuffer.markTokens(JEditBuffer.java:1304)
	at
org.gjt.sp.jedit.textarea.ChunkCache.lineToChunkList(ChunkCache.java:782)
	at
org.gjt.sp.jedit.textarea.ChunkCache.updateChunksUpTo(ChunkCache.java:659)
	at org.gjt.sp.jedit.textarea.ChunkCache.getLineInfo(ChunkCache.java:256)
	at
org.gjt.sp.jedit.textarea.ExtensionManager.paintScreenLineRange(ExtensionManager.java:102)
	at org.gjt.sp.jedit.textarea.Gutter.paintComponent(Gutter.java:130)
	at javax.swing.JComponent.paint(JComponent.java:1027)
	at javax.swing.JComponent.paintToOffscreen(JComponent.java:5122)
	at
javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:285)
	at javax.swing.RepaintManager.paint(RepaintManager.java:1128)
	at javax.swing.JComponent._paintImmediately(JComponent.java:5070)
	at javax.swing.JComponent.paintImmediately(JComponent.java:4880)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:723)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:679)
	at
javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:659)
	at
javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:128)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
	at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
	at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
	at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

jEdit 4.3pre15
XML (and depending plugins)
Sidekick -> parse .php file with the html-parser

java.version=1.6.0_07
java.vm.version=10.0-b23
java.runtime.version=1.6.0_07-b06

Windows XP SP 2

----------------------------------------------------------------------

Comment By: lu10010 (lu10010)
Date: 2008-08-12 04:33

Message:
Logged In: YES 
user_id=1230915
Originator: NO

Again: test with jEdit 4.3pre15 (the same with 14,13,12,11,10...) and
XML/Sidekick:
TextArea painting corruption when saving
screenshot:
http://www.nolink.de/downloads/jedit_bug/jedit4.3.pre15.test.png

----------------------------------------------------------------------

Comment By: lu10010 (lu10010)
Date: 2008-04-18 07:27

Message:
Logged In: YES 
user_id=1230915
Originator: NO

blueyed, no possibility for me to upload files (same as elsie), so only
URL's.

URL for a list of files to download (3 files right click to download:
screenshot and test.php and test.zip (screenshot and test.php))
http://www.nolink.de/downloads/?id=jedit_bug

Direct URL for test.php (only with download manager...):
http://www.nolink.de/downloads/jedit_bug/test.php
Direct URL for test.zip:
http://www.nolink.de/downloads/jedit_bug/test.zip
Direct URL for screenshot:
http://www.nolink.de/downloads/jedit_bug/screenshot.gif

----------------------------------------------------------------------

Comment By: daniel hahler (blueyed)
Date: 2008-04-18 05:48

Message:
Logged In: YES 
user_id=663176
Originator: NO

File Added: 1633393-fix.diff

----------------------------------------------------------------------

Comment By: daniel hahler (blueyed)
Date: 2008-04-18 05:47

Message:
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

----------------------------------------------------------------------

Comment By: lu10010 (lu10010)
Date: 2008-04-18 02:04

Message:
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 

----------------------------------------------------------------------

Comment By: Dale Anson (daleanson)
Date: 2008-03-01 12:05

Message:
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

----------------------------------------------------------------------

Comment By: Dale Anson (daleanson)
Date: 2008-03-01 12:01

Message:
Logged In: YES 
user_id=187628
Originator: NO

Deleting the FastRepaintManger.java.diff patch, it should not be applied. 

----------------------------------------------------------------------

Comment By: Dale Anson (daleanson)
Date: 2008-02-16 21:36

Message:
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.

----------------------------------------------------------------------

Comment By: Dale Anson (daleanson)
Date: 2008-01-31 11:32

Message:
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.  

----------------------------------------------------------------------

Comment By: Dale Anson (daleanson)
Date: 2008-01-26 20:25

Message:
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.

----------------------------------------------------------------------

Comment By: Dale Anson (daleanson)
Date: 2008-01-26 20:23

Message:
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

----------------------------------------------------------------------

Comment By: Dale Anson (daleanson)
Date: 2008-01-26 08:01

Message:
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

----------------------------------------------------------------------

Comment By: Matthieu Casanova (kpouer)
Date: 2007-12-03 05:11

Message:
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)

----------------------------------------------------------------------

Comment By: lu10010 (lu10010)
Date: 2007-08-29 03:26

Message:
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 :-)

----------------------------------------------------------------------

Comment By: Lindsey Simon (elsie)
Date: 2007-08-15 13:56

Message:
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.

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2007-08-14 09:19

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

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2007-07-31 14:01

Message:
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.

----------------------------------------------------------------------

Comment By: Lindsey Simon (elsie)
Date: 2007-07-31 13:48

Message:
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

----------------------------------------------------------------------

Comment By: Jeffrey Hoyt (jchoyt)
Date: 2007-02-13 08:35

Message:
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

----------------------------------------------------------------------

Comment By: Lemon Juice (lemon_juice)
Date: 2007-01-25 00:39

Message:
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. 

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (vanza)
Date: 2007-01-11 22:03

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1633393&group_id=588

[ jEdit-devel ] [ jedit-Bugs-1633393 ] TextArea painting corruption when saving

jEdit is a programmer's text editor written in Java.

[ jEdit-devel ] [ jedit-Bugs-1633393 ] TextArea painting corruption when saving