[gui-dev] Startup deadlock problems

[Jens-Uwe Mager]

On my XP box I have the problem that LimeWire quite fails to start
properly probably one out of three times. I have the same problem under
OS X, although it appears to happen there much more seldom. The problem
manifests itself that main the frame does not appear after the splash
screen is dismissed. Under XP this causes LimeWire to be invisible on
the task bar, one has to use task manager to kill it and try again.
Under OS X the Menu bar with just the LimeWire menu appears but using
the Quit option does nothing, one has to force quite LimeWire to try
again.

This reminded me of an issue I did read in the Java Swing Tutorial,
namely the possible deadlock possible if modifying components that have
already been realized. See:

http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html

After wrapping the call to Initializer.initialize() into a
SwingUtilities.invokeLater() the deadlock does indeed disappear,
although painting of the splash screen does not appear to happen any
more. This appearently means that the construction of the gui needs to
be more cleanly seperated out to avoid threading issues. What do you
think? Am I barking up the wrong tree?

[Sam Berlin]

Hi Jens-Uwe,

What version of Java are you using on the boxes? We have no
experienced these errors, so it is very strange that you are seeing it
1/3 of the time on XP.

I did experiment at one time with putting the initial
GUIMediator.instance call in the Swing thread, but noticed (as you saw)
that the splash screen wasn't updated. The problem was that the update
required the Swing thread to show, but it was blocked by the
construction of the GUI. Rather than try and separate out the
problematic points, it seemed unnecessary to put the construction in
the Swing thread, since there were no problems at the time.

Can you hit 'ctrl-break' during these deadlocks to have Java show where
the deadlock is occurring? (On OSX you can send a kill with the
interrupt signal.)

Thanks,
Sam

Post by Jens-Uwe Mager
On my XP box I have the problem that LimeWire quite fails to start
properly probably one out of three times. I have the same problem under
OS X, although it appears to happen there much more seldom. The problem
manifests itself that main the frame does not appear after the splash
screen is dismissed. Under XP this causes LimeWire to be invisible on
the task bar, one has to use task manager to kill it and try again.
Under OS X the Menu bar with just the LimeWire menu appears but using
the Quit option does nothing, one has to force quite LimeWire to try
again.
This reminded me of an issue I did read in the Java Swing Tutorial,
namely the possible deadlock possible if modifying components that have
http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html
After wrapping the call to Initializer.initialize() into a
SwingUtilities.invokeLater() the deadlock does indeed disappear,
although painting of the splash screen does not appear to happen any
more. This appearently means that the construction of the gui needs to
be more cleanly seperated out to avoid threading issues. What do you
think? Am I barking up the wrong tree?
--
Jens-Uwe Mager <pgp-mailto:F476EBC2>
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev

[Jens-Uwe Mager]

Post by Sam Berlin
What version of Java are you using on the boxes? We have no
experienced these errors, so it is very strange that you are seeing it
1/3 of the time on XP.

I am using on XP:

java version "1.4.2_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode)

Post by Sam Berlin
I did experiment at one time with putting the initial
GUIMediator.instance call in the Swing thread, but noticed (as you saw)
that the splash screen wasn't updated. The problem was that the update
required the Swing thread to show, but it was blocked by the
construction of the GUI. Rather than try and separate out the
problematic points, it seemed unnecessary to put the construction in
the Swing thread, since there were no problems at the time.
Can you hit 'ctrl-break' during these deadlocks to have Java show where
the deadlock is occurring? (On OSX you can send a kill with the
interrupt signal.)

Oh, I did not know about the ctrl-break trick to get a stack dump. I am
now seeing that it deadlocks in the GUI initialization of a custom tab I
added to my version of LimeWire, that is the reason you did not see the
problem. I will probably need to shield that part of the initialization
with SwingUtilities.invokeLater. But it appears to me that the whole
thing is a bit fragile, changing a few minor things in the
initialization sequence might produce a similar problem in stock
LimeWire as well.

[Sam Berlin]

Post by Jens-Uwe Mager
it deadlocks in the GUI initialization of a custom tab I
added to my version of LimeWire, that is the reason you did not see the
problem. I will probably need to shield that part of the initialization
with SwingUtilities.invokeLater. But it appears to me that the whole
thing is a bit fragile, changing a few minor things in the
initialization sequence might produce a similar problem in stock
LimeWire as well.

Yeah, the startup is pretty fragile. We'll gladly accept a patch that
puts the construction in the Swing thread & still manages to update the
splash screen. :)

Thanks,
Sam

[Jens-Uwe Mager]

Post by Sam Berlin
Yeah, the startup is pretty fragile. We'll gladly accept a patch that
puts the construction in the Swing thread & still manages to update the
splash screen. :)

OK, it does not need to be that an intrusive patch to get it working
properly. Sprinkleing a few SwingUtilities.invokeAndWait() into the
source does it. I did change the following three places that are prone
to the deadlock problem:

* SplashWindow: updating the status text modifies a realized window.
* StatusLine: same problem.
* GUIMediator.setAppVisible: making the main frame visible while other
threads do updates to the GUI already (via SwingUtilities.invokeLater)
produces a dead lock main thread against the Swing event dispatcher
thread.

Especially the third one is the one that affected my additional main
tab, it implements a scrollable console window via BeanShell that may
already do prints to a console window. This is in particular visible if
logging via log4j is redirected to the console window.

The attached patch does indeed make the deadlock go away, but it appears
to have one side effect under Windows that I do not understand. The
code that does iconify LimeWire to the system tray does not
appear to work with my patch, it simply iconifies to the task bar. The
code appears to be highly magical, do you have any clues what might be
causing the breakage?

[Jens-Uwe Mager]

Oops, I cleaned up the patch to work properly in the case the code
already runs on the event dispatcher thread.

[Jens-Uwe Mager]

Post by Jens-Uwe Mager
Oops, I cleaned up the patch to work properly in the case the code
already runs on the event dispatcher thread.

This also appears to have fixed the problem with iconfying to the system
tray icon.