Return-Path: Delivered-To: apmail-harmony-commits-archive@www.apache.org Received: (qmail 56588 invoked from network); 11 Oct 2007 08:59:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Oct 2007 08:59:41 -0000 Received: (qmail 53683 invoked by uid 500); 11 Oct 2007 08:59:29 -0000 Delivered-To: apmail-harmony-commits-archive@harmony.apache.org Received: (qmail 53666 invoked by uid 500); 11 Oct 2007 08:59:29 -0000 Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list commits@harmony.apache.org Received: (qmail 53651 invoked by uid 99); 11 Oct 2007 08:59:29 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Oct 2007 01:59:29 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Oct 2007 08:59:41 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id DC75F714236 for ; Thu, 11 Oct 2007 01:58:50 -0700 (PDT) Message-ID: <3950829.1192093130898.JavaMail.jira@brutus> Date: Thu, 11 Oct 2007 01:58:50 -0700 (PDT) From: "Andrey Pavlenko (JIRA)" To: commits@harmony.apache.org Subject: [jira] Commented: (HARMONY-4762) [classlib][swing][html] Flaw in thread synchronization in BasicTextUI In-Reply-To: <24423292.1189178670826.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HARMONY-4762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533987 ] Andrey Pavlenko commented on HARMONY-4762: ------------------------------------------ Alexey, the issue occurs because the field "document" could be changed between invocations of readLock/Unlock. So, we have situation when we lock one document but unlock another. I've created local variables to ensure the invocation of lock/unlock on the same document. > [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.