harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Pavlenko (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HARMONY-4762) [classlib][swing][html] Flaw in thread synchronization in BasicTextUI
Date Wed, 10 Oct 2007 13:27:52 GMT

     [ https://issues.apache.org/jira/browse/HARMONY-4762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andrey Pavlenko updated HARMONY-4762:
-------------------------------------

    Attachment: HARMONY-4762-BasicTextUI.patch

I've reimplemented the synchronization to use local variables for locking/unlocking instead
of the "document" field. Vasily, could you please check this patch?

> [classlib][swing][html] Flaw in thread synchronization in BasicTextUI
> ---------------------------------------------------------------------
>
>                 Key: HARMONY-4762
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4762
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>            Reporter: Vasily Zakharov
>         Attachments: HARMONY-4762-BasicTextUI.patch
>
>
> javax.swing.plaf.basic.BasicTextUI has a synchronization mechanism implemented in readLock()/readUnlock()
methods. These methods forward the calls to the corresponding methods of AbstractDocument
class instance in document field.
> This mechanism has a flaw - sometimes the document field gets replaced by another thread
between calls to readLock() and readUnlock(). This makes the readUnlock() call to fail.
> Here's the simple reproducer:
> import javax.swing.JEditorPane;
> import javax.swing.JFrame;
> public class Test {
>     public static void main(String argv[]) {
>         try {
>             JFrame frame = new JFrame("Test");
>             frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>             frame.setSize(100, 100);
>             JEditorPane pane = new JEditorPane();
>             frame.add(pane);
>             frame.setVisible(true);
>             pane.setPage("file:test.html");
>         } catch (Throwable e) {
>             e.printStackTrace(System.out);
>         }
>     }
> }
> test.html should exist in current directory and may be empty.
> This test produces the following exception on Harmony: 
> java.lang.Error: This thread doesn't hold read lock.
>         at javax.swing.text.AbstractDocument$ReadWriteLock.readUnlock(AbstractDocument.java:868)
>         at javax.swing.text.AbstractDocument.readUnlock(AbstractDocument.java:1142)
>         at javax.swing.plaf.basic.BasicTextUI.readUnlock(BasicTextUI.java:114)
>         at javax.swing.plaf.basic.BasicTextUI.paintSafely(BasicTextUI.java:844)
>         at javax.swing.plaf.basic.BasicTextUI.paint(BasicTextUI.java:88)
>         at javax.swing.plaf.ComponentUI.update(ComponentUI.java:38)
>         at javax.swing.plaf.basic.BasicTextUI.update(BasicTextUI.java:956)
>         at javax.swing.JComponent.paintComponent(JComponent.java:897)
>         at javax.swing.JComponent.paint(JComponent.java:994)
>         at javax.swing.JComponent.paintDoubleBuffered(JComponent.java:1425)
>         at javax.swing.JComponent.paintImmediately(JComponent.java:156)
>         at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:186)
>         at javax.swing.RepaintManager$1.run(RepaintManager.java:80)
>         at java.awt.event.InvocationEvent.runAndNotify(InvocationEvent.java:98)
>         at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:78)
>         at java.awt.EventQueueCore.dispatchEventImpl(EventQueueCore.java:138)
>         at java.awt.EventQueue.dispatchEvent(EventQueue.java:144)
>         at java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:74)
>         at java.awt.EventDispatchThread.run(EventDispatchThread.java:48)
> The AbstractDocument instance mentioned on top of this stack is not the instance readLock()
was called for.
> The error is intermittent and occurs not so often. To make it stable, one can add Thread.sleep(100)
call to javax.swing.text.html.BlockView.paint() method as follows:
>     public void paint(final Graphics g, final Shape allocation) {
>         Rectangle rc = allocation.getBounds();
>         try {
>             Thread.sleep(100);
>         } catch (InterruptedException e) {}
>         boxPainter.paint(g, rc.x, rc.y, rc.width, rc.height, this);
>         super.paint(g, allocation);
>     }
> This change doesn't alter the code logic, but slows it down and makes the error to show
off much more often.
> This issue was discovered while investigating HARMONY-4755.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message