Hi, Getting everything out of the way, here's an analysis of the problem below...
I made a standalone version of the testcase. With this, the problem only shows up maybe 1 time out of 5, and so it is timing related. It is an example of the "classic" deadlock case, where two threads attempt to obtain the same locks but in a different order. The first thread is the main thread. This thread creates the child JComponent and adds it to the JFrame. It then synchronises on the vars Vector and attempts f.setVisible(true). The second thread is the AWT event thread (AWT-EventQueue-1). When the deadlock occurs, it is performing a paint of the newly added JComponent. This is called within the paint method of the parent Container. Its visitChildren method obtains the AWT tree lock (getTreeLock()). Within the child paint method it then attempts to obtain the lock on the vars Vector (the vars.add calls a synchronised method). The AWT event thread is unable to obtain the vars Vector lock because it is held by the main thread. The main thread in the meantime is attempting f.setVisible(true). This calls getComponents on the Container, which attempts to obtain the tree lock. It is unable to get this lock because it is held by the AWT event thread. Each thread is waiting on the other -- neither will release the lock the other is waiting on, and we therefore have a deadlock. It is clearly not a bug in JamVM. Perhaps the tree lock should be released on calling the child paint method (taking into account possible changes to the component list on return)? I am undecided as to whether the testcase itself is correct. Rob. On Mon, 13 Dec 2004 12:44:37 +0100, Thomas Zander <[EMAIL PROTECTED]> wrote: > Would anyone have problems with me committing a mauve test that opens a > Window for a very little time? > > See attached test. > > Next to that; I would like to ask for your expertise to see if I made a > mistake, or if there is a bug in classpath/jamvm. > The statement on line 75 (setVisible()) should be inside the synchronized > block, but if I do that then the frame is properly displayed, but never > returns. Putting a System.exit(); before the "try {" line made me sure it > really never returns. > > Any ideas? > -- > Thomas Zander > > > _______________________________________________ > Classpath mailing list > Classpath@gnu.org > http://lists.gnu.org/mailman/listinfo/classpath > > > > _______________________________________________ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath