harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chunrong Lai (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-4624) [classlib][swing]SplitPane triggers the deadlock in AbstractDocument$ReadWriteLock
Date Wed, 15 Aug 2007 08:25:31 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519896
] 

Chunrong Lai commented on HARMONY-4624:
---------------------------------------


   Yes I do mean that I have two threads operates at different components of the SplitPane.
I think it should be thread-safe (at least thread-safe to other VMs). But it just hangs in
Harmony with below stacktrace (of the RightComponent). When it happens the thread of the LeftComponent
should have increased the writercount.
   I am sorry that my scenario is too large to attach here. It is also difficult to gnerate
a small reproducer to represent the specific multi-threading bug.
   Anyway here is the trace to readLock() (for LeftComponent) from the change of RightComponent
(by resetToPreferredSizes):

javax.swing.text.AbstractDocument$ReadWriteLock.readLock(AbstractDocument.java:855)
        at javax.swing.text.AbstractDocument.readLock(AbstractDocument.java:1139)
        at javax.swing.text.RootView.readLock(RootView.java:295)
        at javax.swing.text.RootView.getPreferredSpan(RootView.java:166)
        at javax.swing.plaf.basic.BasicTextUI.getPreferredSize(BasicTextUI.java:515)
        at javax.swing.JComponent.getPreferredSize(JComponent.java:468)
        at javax.swing.JEditorPane.getPreferredSize(JEditorPane.java:376)
        at javax.swing.text.JTextComponent.getPreferredScrollableViewportSize(JTextComponent.java:1131)
        at javax.swing.ViewportLayout.preferredLayoutSize(ViewportLayout.java:87)
        at javax.swing.JComponent.getPreferredSize(JComponent.java:474)
        at javax.swing.ScrollPaneLayout.preferredLayoutSize(ScrollPaneLayout.java:187)
        at javax.swing.JComponent.getPreferredSize(JComponent.java:474)
        at java.awt.BorderLayout.validateArrays(BorderLayout.java:440)
        at java.awt.BorderLayout.validate(BorderLayout.java:398)
        at java.awt.BorderLayout.minimumLayoutSize(BorderLayout.java:273)
        at javax.swing.JComponent.getMinimumSize(JComponent.java:439)
        at javax.swing.plaf.basic.BasicTabbedPaneUI$TabbedPaneLayout.calculateContentAreaSize(BasicTabbedPaneUI.java:204)
        at javax.swing.plaf.basic.BasicTabbedPaneUI$TabbedPaneLayout.calculateSize(BasicTabbedPaneUI.java:165)
        at javax.swing.plaf.basic.BasicTabbedPaneUI$TabbedPaneLayout.minimumLayoutSize(BasicTabbedPaneUI.java:375)
        at javax.swing.JComponent.getMinimumSize(JComponent.java:439)
        at javax.swing.plaf.basic.BasicSplitPaneUI.getMinimumSizeOfComponent(BasicSplitPaneUI.java:857)
        at javax.swing.plaf.basic.BasicSplitPaneUI.access$3(BasicSplitPaneUI.java:849)
        at javax.swing.plaf.basic.BasicSplitPaneUI$BasicHorizontalLayoutManager.resetToPreferredSizes(BasicSplitPaneUI.java:276)
        at javax.swing.plaf.basic.BasicSplitPaneUI$BasicHorizontalLayoutManager.addLayoutComponent(BasicSplitPaneUI.java:184)
        at javax.swing.plaf.basic.BasicSplitPaneUI$BasicHorizontalLayoutManager.addLayoutComponent(BasicSplitPaneUI.java:251)
        at java.awt.Container.addToLayout(Container.java:390)
        at java.awt.Container.addImpl(Container.java:422)
        at javax.swing.JSplitPane.addImpl(JSplitPane.java:358)
        at java.awt.Container.add(Container.java:245)
        at javax.swing.JSplitPane.setBottomComponent(JSplitPane.java:189)

> [classlib][swing]SplitPane triggers the deadlock in AbstractDocument$ReadWriteLock
> ----------------------------------------------------------------------------------
>
>                 Key: HARMONY-4624
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4624
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>         Environment: win32
>            Reporter: Chunrong Lai
>            Assignee: Alexey Petrenko
>         Attachments: h4624.workaround.patch
>
>
>  Dead lock possibilities are seen in the synchronized metnods of AbstractDocument$ReadWriteLock.

>         public final synchronized void readLock() {
>             final Thread thread = Thread.currentThread();
>             if (writer != thread) {
>                 while (writerCount > 0) {
>                     try { wait(); } 
>                     catch (final InterruptedException e) { }
>                 }
>             }
>             readers.add(thread);
>         }
>  Waiting in synchronized methods (requires another synchronized method to wakeup it)
likely just  dies there.
>  Multithreaded SplitPane application triggers the possibility. One thread can operate
at the texts of the LeftComponent, thus in a critical section after setting writercount(writeLock()).
The other thread can operate at the rightComponent, then call the readLock() of LeftComponent
via layout managment and just waits there. 
>  Attach patch eliminates the said intra-splitpane-lock-acquirement. But it is more likely
a workaround.
>  

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