United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6606443 : Infinite loop in FlowView.layout when using HTML tables in JEditorPane

Details
Type:
Bug
Submit Date:
2007-09-19
Status:
Closed
Updated Date:
2011-05-17
Project Name:
JDK
Resolved Date:
2011-05-17
Component:
client-libs
OS:
linux,windows_xp
Sub-Component:
javax.swing
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:

Related Reports
Backport:
Duplicate:
Duplicate:
Duplicate:
Duplicate:

Sub Tasks

Description
FULL PRODUCT VERSION :
java version "1.6.0_02"
Java(TM) SE Runtime Environment (build 1.6.0_02-b05)
Java HotSpot(TM) Client VM (build 1.6.0_02-b05, mixed mode, sharing)


ADDITIONAL OS VERSION INFORMATION :
Windows XP, Linux 2.6.10

A DESCRIPTION OF THE PROBLEM :
I think the fix for Bug 6452106 has caused a regression.

My app displays some business object bean properties using HTML tables (including nested tables) and a CSS style sheet.  We update the inner table elements using setInnerHTML() as the bean properties change.

With Java 1.6.0_01 and 1.6.0_02 (but not with Java 5 or earlier) the JEditorPane freezes up occasionally.  It's not thread deadlock.  Thread dump and debugging reveal we are in an infinite loop in the following recently-added lines in FlowView.FlowStrategy.layout (lines 429-431 of FlowView.java in JDK1.6.0_02):

                // In some cases there's no view at position damageStart, so
                // step back and search again. See 6452106 for details.
                while ((rowIndex = fv.getViewIndexAtPosition(damageStart)) < 0) {
                    damageStart--;
                }


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
In my application I open the JEditorPane window, click a couple of buttons that cause the HTML content to be changed as described above using setInnerHTML(), and move my mouse around a bit while the repainting goes on.  I can somewhat reliably get the infnite loop and must kill the app (kill -TERM or -INT works fine since only the EDT is looping, other threads are o.k.)

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
In JDK 1.4.2 and JDK 5.0 the JEditorPane displays my tables properly and no hang occurs.
ACTUAL -
Infinite loop in FlowView.FlowStrategy.layout().

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Here is the stack trace from the relevant thread.

"AWT-EventQueue-1" prio=10 tid=0x08272400 nid=0x5274 runnable [0xb4fd9000..0xb4fda700]
   java.lang.Thread.State: RUNNABLE
        at javax.swing.text.GapContent$StickyPosition.getOffset(GapContent.java:288)
        at javax.swing.text.AbstractDocument$LeafElement.getStartOffset(AbstractDocument.java:2516)
        at javax.swing.text.AbstractDocument$BranchElement.getStartOffset(AbstractDocument.java:2313)
        at javax.swing.text.View.getStartOffset(View.java:790)
        at javax.swing.text.FlowView.getViewIndexAtPosition(FlowView.java:138)
        at javax.swing.text.FlowView$FlowStrategy.layout(FlowView.java:429)
        at javax.swing.text.FlowView.layout(FlowView.java:184)
        at javax.swing.text.BoxView.setSize(BoxView.java:380)
        at javax.swing.text.BoxView.updateChildSizes(BoxView.java:349)
        at javax.swing.text.BoxView.setSpanOnAxis(BoxView.java:331)
        at javax.swing.text.BoxView.layout(BoxView.java:691)
        at javax.swing.text.BoxView.setSize(BoxView.java:380)
        at javax.swing.text.BoxView.updateChildSizes(BoxView.java:344)
        at javax.swing.text.BoxView.setSpanOnAxis(BoxView.java:317)
        at javax.swing.text.BoxView.layout(BoxView.java:691)
        at javax.swing.text.BoxView.setSize(BoxView.java:380)
        at javax.swing.text.BoxView.updateChildSizes(BoxView.java:349)
        at javax.swing.text.BoxView.setSpanOnAxis(BoxView.java:331)
        at javax.swing.text.BoxView.layout(BoxView.java:691)
        at javax.swing.text.BoxView.setSize(BoxView.java:380)
        at javax.swing.text.BoxView.updateChildSizes(BoxView.java:349)
        at javax.swing.text.BoxView.setSpanOnAxis(BoxView.java:331)
        at javax.swing.text.BoxView.layout(BoxView.java:691)
        at javax.swing.text.BoxView.setSize(BoxView.java:380)
        at javax.swing.text.BoxView.updateChildSizes(BoxView.java:349)
        at javax.swing.text.BoxView.setSpanOnAxis(BoxView.java:331)
        at javax.swing.text.BoxView.layout(BoxView.java:691)
        at javax.swing.text.BoxView.setSize(BoxView.java:380)
        at javax.swing.plaf.basic.BasicTextUI$RootView.setSize(BasicTextUI.java:1701)
        at javax.swing.plaf.basic.BasicTextUI.modelToView(BasicTextUI.java:1033)
        at javax.swing.text.DefaultCaret.repaintNewCaret(DefaultCaret.java:1291)
        at javax.swing.text.DefaultCaret$1.run(DefaultCaret.java:1270)
        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)




REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
I have been working all day to try to create a self-contained HTML table and sequence of updates and mouse events that demonstrate the error, but have not been able to do so.

I am using a subclass of JEditorPane with setEditable(false) and the "text/html" content type (e.g. HTMLEditorKit).

Upon request, I'll be happy to provide the HTML document (JEditorPane.getText) as dumped by a shutdown hook after one of the freezes (note simply loading that HTML into a new JEditorPane does not trigger the bug).

I can also provide the AbstractDocument.dump() output.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
I have not found a workaround.  Since I'm generating the HTML automatically, I've examined the <P> and <TABLE> tags and played with the structure of whitespace between tags and such.

Release Regression From : 6
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.

                                    

Comments
EVALUATION

The problem most likely happens when a chunk of text is replaced with another one, e.g. select a line and press Enter. In this case, the old chunk is removed first. A FlowView receives removeUpdate notification and remembers its position in the damageStart variable. Then an insert occurs before that FlowView, so the View's start offset moves forward. Later when the view is layed out, it finds that damageStart is less than startOffset, so getViewIndexAtPosition() returns -1.
                                     
2007-09-20



Hardware and Software, Engineered to Work Together