JDK-6892485 : Deadlock in SunGraphicsEnvironment / FontManager
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6u10,7
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,linux
  • CPU: generic,x86
  • Submitted: 2009-10-16
  • Updated: 2011-01-14
  • Resolved: 2010-03-17
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.
JDK 7 Other
7 b86Fixed OpenJDK6Fixed
Related Reports
Duplicate :  
JDK-6921601 - Deadlock: sun.font.FontManager.findFont2D
Description
A developer reported here
http://mail.openjdk.java.net/pipermail/2d-dev/2009-September/001013.html
and follow ups here
http://mail.openjdk.java.net/pipermail/2d-dev/2009-October/001031.html

a problem as described below

We have an application running on OpenJDK6 that seems to be
deadlocking in SunGraphicsEnvironment.  I found it rather difficult to
write a cut-down reproduction, but the errant lock acquisition is on
line 482 of SunGraphicsEnvironment.java.:

http://hg.openjdk.java.net/jdk6/jdk6-gate/jdk/file/f9fa5c538031/src/share/classes/sun/java2d/SunGraphicsEnvironment.java

After the lock is acquired, it goes on to call
FontManager.initialiseDeferredFonts() on line 467, which acquires the
other lock.  It looks as if you might be able to move the lock
acquisition from line 462 to 468, which would eliminate the deadlock.
The code looks pretty similar in recent OpenJDK7 builds (although the
line numbers are changed).

The relevant stacks follow.  It seems like a pretty easy fix for a
pretty nasty problem.  Any chance someone could take a look?  Thanks!

Thread 1:
 sun.font.FontManager.initialiseDeferredFonts(FontManager.java:791)
 sun.java2d.SunGraphicsEnvironment.loadFonts(SunGraphicsEnvironment.java:467)
 sun.awt.X11GraphicsEnvironment.loadFonts(X11GraphicsEnvironment.java:885)
 sun.font.FontManager.findFont2D(FontManager.java:1995)
 java.awt.Font.getFont2D(Font.java:473)
 java.awt.Font.getFontName(Font.java:1221)
 java.awt.Font.getFontName(Font.java:1203)

Thread 2:
 sun.java2d.SunGraphicsEnvironment.loadFonts(SunGraphicsEnvironment.java:463)
 sun.awt.X11GraphicsEnvironment.loadFonts(X11GraphicsEnvironment.java:885)
 sun.font.FontManager.findFont2D(FontManager.java:1995)
 sun.font.FontManager.getDefaultPhysicalFont(FontManager.java:1071)
 sun.font.FontManager.initialiseDeferredFont(FontManager.java:960)
 sun.font.FontManager.findJREDeferredFont(FontManager.java:875)
 sun.font.FontManager.findDeferredFont(FontManager.java:912)
 <snip lots of recursion>
 sun.font.FontManager.findFont2D(FontManager.java:1904)
 sun.font.FontManager.findFont2D(FontManager.java:1865)
 java.awt.Font.getFont2D(Font.java:473)
 java.awt.Font.getFontName(Font.java:1221)
 java.awt.Font.getFontName(Font.java:1203)
Comments
EVALUATION The submitter proposed moving the lock but that same lock is taken later and so it doesn't guarantee to fix the problem. Options I see right now are 1) Simplify this down to one lock : the FontManager.class one, using it instead of the SunGraphicsEnvironment.lucidaFontName lock 2) Eliminate the lock here and rely on checks in the registration methods by font file name to skip over much of the duplicate work that might ensue from letting two threads have at this at the same time.
16-10-2009