JDK-4668511 : Deadlock in JColorChooser
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2002-04-15
  • Updated: 2002-06-13
  • Resolved: 2002-04-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.1 hopperFixed
Description
There is a problem with JColorChooser that can cause an entire GUI application to freeze permanently.

To reproduce:

Run SwingSet2.
Switch to the JColorChooser demo.
Switch to the HSB tab.
Click on the "S" radiobutton repeatedly.
The entire application freezes.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: hopper FIXED IN: hopper INTEGRATED IN: hopper VERIFIED IN: hopper-beta
14-06-2004
EVALUATION The problem is that DefaultHSBChooserPanel re-uses its AbstractHSBImages with new ImageIcons. AbstractHSBImages have the concept of being dirty. When not dirty, their computeRow method will wait() until they are dirty before generating more data. Now, when multiple ImageIcons are created to use the same AbstractHSBImage, the AbstractHSBImage creates a Thread to produce data for each consumer. When it is set to be dirty, all threads wake up, one begins processing, but then sets it back to dirty. The other threads therefore wait again. Thus the GUI freezes. I have changed DefaultHSBChooserPanel such that the same ImageIcons are used throughout most of the life of the JColorChooser and each one has its own producer thread. These objects are destroyed (and threads stopped) only when the component is made undisplayable (if it is made displayable again then they are re-created). I have basically made sure that there is always a one-to-one correspondence between image consumers (ImageIcon in this case) and image producer threads. ###@###.### 2002-04-15
15-04-2002