JDK-4705104 : Notepad hangs up when open uigur text in gb18030 locale.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.3.1,1.4.0,1.4.1
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    solaris_2.6,solaris_9,windows_2000,windows_xp solaris_2.6,solaris_9,windows_2000,windows_xp
  • CPU: x86,sparc
  • Submitted: 2002-06-20
  • Updated: 2003-07-11
  • Resolved: 2003-07-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0 tigerFixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Description
###@###.### 2002-11-05

Exception described below is no longer reproducible in latest build, but Notepad
hangs up when open uigur text file, it only happens in gb18030 locale (both
on Solaris 9 and Windows w2k machine).


hopper b14

reproduce:

login in s9 gb18030 locale
java -jar Notepad.jar
Then open attachment txt file which is uigur character for chinese, will get this exception.

java.lang.IllegalArgumentException: bad start (0) or length (-1)
        at sun.awt.font.StandardTextSource.getSubSource(StandardTextSource.java:
169)
        at sun.awt.font.ExtendedTextSourceLabel.getSubset(ExtendedTextSourceLabe
l.java:748)
        at java.awt.font.TextMeasurer.makeComponentsOnRange(TextMeasurer.java:44
2)
        at java.awt.font.TextMeasurer.makeTextLineOnRange(TextMeasurer.java:473)

        at java.awt.font.TextMeasurer.getLayout(TextMeasurer.java:606)
        at java.awt.font.LineBreakMeasurer.nextLayout(LineBreakMeasurer.java:427
)
        at javax.swing.text.TextLayoutStrategy.createView(TextLayoutStrategy.jav
a:197)
        at javax.swing.text.FlowView$FlowStrategy.layoutRow(FlowView.java:442)
        at javax.swing.text.TextLayoutStrategy.layoutRow(TextLayoutStrategy.java
:109)
        at javax.swing.text.FlowView$FlowStrategy.layout(FlowView.java:398)
        at javax.swing.text.TextLayoutStrategy.layout(TextLayoutStrategy.java:92
)
        at javax.swing.text.FlowView.layout(FlowView.java:182)
        at javax.swing.text.BoxView.setSize(BoxView.java:379)
        at javax.swing.plaf.basic.BasicTextAreaUI$PlainParagraph.setSize(BasicTe
xtAreaUI.java:205)
        at javax.swing.text.BoxView.updateChildSizes(BoxView.java:348)
        at javax.swing.text.BoxView.setSpanOnAxis(BoxView.java:330)
        at javax.swing.text.BoxView.layout(BoxView.java:682)
        at javax.swing.text.BoxView.setSize(BoxView.java:379)
        at javax.swing.plaf.basic.BasicTextUI$RootView.setSize(BasicTextUI.java:
1598)
        at javax.swing.plaf.basic.BasicTextUI.getPreferredSize(BasicTextUI.java:
800)
        at javax.swing.JComponent.getPreferredSize(JComponent.java:1272)
        at javax.swing.JTextArea.getPreferredSize(JTextArea.java:606)
        at javax.swing.ScrollPaneLayout.layoutContainer(ScrollPaneLayout.java:76
9)
        at java.awt.Container.layout(Container.java:1017)
        at java.awt.Container.doLayout(Container.java:1007)
        at java.awt.Container.validateTree(Container.java:1089)
        at java.awt.Container.validate(Container.java:1064)
        at javax.swing.RepaintManager.validateInvalidComponents(RepaintManager.j
ava:353)
        at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(System
EventQueueUtilities.java:116)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:448)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchTh
read.java:197)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThre
ad.java:150)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144)

        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136)

        at java.awt.EventDispatchThread.run(EventDispatchThread.java:99)


But get rid of the last column(cut -f1,2 -d " " GB18030_uigur.txt > 1.txt ), then open 1.txt will ok.

please get Notepad.jar, GB18030_uigur.txt from attachment .
And the Notepad.java is the modify source from Demo, other part same in Demo.



Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b11
14-06-2004

EVALUATION need further investigation, target for mantis ###@###.### 2002-06-20 For a swing text component which uses AbstractDocument class, if I have two threads A and B calling the code paths as showed below a deadlock will occurs in scenario like A: obtained the writeLock on AbstractDocument and then goes on, B: obtained AwtTreeLock() A: reached the point of trying getting AWTTreeLock(), waiting for (B) to release AWTTreeLock. B: reached the point of trying getting AbstractDocument.readLock(), waiting (A) to release writeLock. This is actually happening when using Notepad to read in an Uigar document on GB18030 locale (as far as I have tried, it only happens in gb18030 locale, guess it might be caused by the "big" gb18030 font file which makes some bidi operations slow, only a guess though), A is the Notepad's FileLoader thread and B is the awt EventDispatchThread to repaint the window after the FileDialog is closed. On theory, fireChangedUpdate(), fireRemoveUpdate(), fireUndoableEditUpdate all have the same risk of causing a deadlock like this. Thread A code path: insertString() writeLock() handleInsertString() fireInsertUpdate() DocumentListener.insertUpdate() (plaf.basic.BasicTextUI$UpdateHandler.insertUpdate()) plaf.basic.BasicTextUI.modelChanged() plaf.basic.BasicTextUI.setView() awt.Contailer.removeAll() java.awt.Component$AWTTreeLock() writeUnlock() Thread B code path: JComponent.paintComponent ... java.awt.Component$AwtTreeLock() ... plaf.basic.BasicTextUI.update() plaf.basic.BasicTextUI.paint() text.AbstractDocument.readLock() assign to swing team. ###@###.### 2002-11-05 Name: anR10225 Date: 06/11/2003 This bug could be reproduced when complex text is inserted into AbstractDocument and its 'i18n' property is changed. To reproduce it I've also inserted a timeout and a monitor into JComponent and BasicTextUI classes. Here are stack traces of EventDispatch and the main thread when a deadlock occurs : Main: AWTTreeLock removeAll():783, java.awt.Container setView():600, javax.swing.plaf.basic.BasicTextUI modelChanged():589, javax.swing.plaf.basic.BasicTextUI insertUpdate():1745, javax.swing.plaf.basic.BasicTextUI$UpdateHandler fireInsertUpdate():184, javax.swing.text.AbstractDocument doc.writeLock handleInsertString():749, javax.swing.text.AbstractDocument insertString():706, javax.swing.text.AbstractDocument insertString():114, javax.swing.text.PlainDocument EDT: readLock():1387, javax.swing.text.AbstractDocument doc.readLock paint():786, javax.swing.plaf.basic.BasicTextUI update():760, javax.swing.plaf.basic.BasicTextUI paintComponent():545, javax.swing.JComponent paint():817, javax.swing.JComponent paintChildren():654, javax.swing.JComponent paint():826, javax.swing.JComponent paintChildren():654, javax.swing.JComponent paint():826, javax.swing.JComponent paint():557, javax.swing.JLayeredPane AWTTreeLock paintChildren():654, javax.swing.JComponent paintWithOffscreenBuffer():4854, javax.swing.JComponent paintDoubleBuffered():4800, javax.swing.JComponent paint():807, javax.swing.JComponent run():21, java.awt.GraphicsCallback$PaintCallback runOneComponent():60, sun.awt.SunGraphicsCallback runComponents():97, sun.awt.SunGraphicsCallback paint():1312, java.awt.Container The reason is in editor.removeAll() invocation in BasicTextUI.setView() method. This call was intended to remove embedded components (e.g. HTML input field) from their hosting container. But currently this task is performed by the ComponentView in more safe way (in EDT) when its parent is set to null. Currently BasicTextUI.RootView.setView() invokes oldView.setParent(null). So I suppose 'editor.removeAll()' should be removed from BasicTextUI.setView() method. ======================================================================
11-06-2004

SUGGESTED FIX Name: anR10225 Date: 06/16/2003 *** src/share/classes/javax/swing/plaf/basic/BasicTextUI.java- --- BasicTextUI.java *************** *** 596,602 **** * @param v the root view */ protected final void setView(View v) { - editor.removeAll(); rootView.setView(v); painted = false; editor.revalidate(); --- 596,601 ---- ======================================================================
11-06-2004