United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6892485 Deadlock in SunGraphicsEnvironment / FontManager
JDK-6892485 : Deadlock in SunGraphicsEnvironment / FontManager

Details
Type:
Bug
Submit Date:
2009-10-16
Status:
Resolved
Updated Date:
2011-01-14
Project Name:
JDK
Resolved Date:
2010-03-17
Component:
client-libs
OS:
linux,generic
Sub-Component:
2d
CPU:
x86,generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
6u10,7
Fixed Versions:

Related Reports
Backport:
Backport:
Duplicate:

Sub Tasks

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.
                                     
2009-10-16



Hardware and Software, Engineered to Work Together