JDK-6548757 : Crash in fontmanager.dll on windows-amd64
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6u2,7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_2003,windows_xp
  • CPU: x86
  • Submitted: 2007-04-21
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
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 6 JDK 7
6u2Fixed 7 b14Fixed
Related Reports
Duplicate :  
JDK-6558151 - 10 tests pass jdk6.0u01b06 but fail on jdk6.0u2b01 and jdk6.0u2b02
Duplicate :  
JDK-6547493 - CTE test 4832671 failed on 60u2b01 but passed on previous one 60u1b06
Description
Following testcase crashes on windows-amd64 with jdk7(b10,b11), jdk6u2 but doesn't with jdk6b98:

import javax.swing.JFrame;
import javax.swing.UIManager;

public class Test {

    public static void main(String[] args) {
        try {
            UIManager.setLookAndFeel(
                    UIManager.getSystemLookAndFeelClassName());
        } catch (Exception ex) {
            System.out.println("Unable to load native look and feel");
        }
        (new JFrame()).setVisible(true);
    }
}

Here is the stack trace from crash dump:

ntdll!ZwWaitForSingleObject+0xa
kernel32!WaitForSingleObjectEx+0x130
faultrep!InternalGenerateMinidumpEx+0x722
faultrep!InternalGenerateMinidump+0x10a
faultrep!InternalGenFullAndTriageMinidumps+0xfb
faultrep!ReportFaultDWM+0x731
faultrep!StartManifestReportImmediate+0x2c0
faultrep!ReportFault+0x3ca
kernel32!UnhandledExceptionFilter+0x629
fontmanager!__report_gsfailure+0xec [d:\srvrtm\base\tools\gs_support\umode\gs_report.c @136]
fontmanager!DifferentFamily+0xb9 [d:\export\java2d\j2se\src\windows\native\sun\font\fontpath.c @ 195]
fontmanager!EnumFontFacesInFamilyProcW+0x60 [d:\export\java2d\j2se\src\windows\native\sun\font\fontpath.c @ 217]
gdi32!EnumFontsInternalW+0x1e6
gdi32!EnumFontFamiliesExW+0x48
fontmanager!EnumFamilyNamesW+0x239 [d:\export\java2d\j2se\src\windows\native\sun\font\fontpath.c @ 341]
gdi32!EnumFontsInternalW+0x1e6
gdi32!EnumFontFamiliesExW+0x48
fontmanager!Java_sun_font_FontManager_populateFontFileNameMap+0x383 [d:\export\java2d\j2se\src\windows\native\sun\font\fontpath.c @ 604]
0x209fcc4
0x1fde7a8
Comments
EVALUATION Submitter confirms he has such fonts and the suggested fix resolves it.
24-04-2007
EVALUATION >fontmanager!DifferentFamily+0xb9 This function is new in 6u2 b01 and JDK7 b08. It was added in fixing 6517861 I am reasonably windows is trying to report a buffer overflow. the gs_restore function looks to be associated with the newer compiler used to build for x64. But I see a silent exit on windows 2003 server x64, not a crash I looked at the new code in 6u2 b01 and noticed in order to do a check we need to copy a full name from one windows data structure (ENUMLOGFONTEX.elfFullName) into a field used to hold a face name in a different windows data structure (LOGFONT.lfFaceName). It appears that the former has a size of LF_FULLFACESIZE (64 chars) whereas the later has a size of LF_FACESIZE (32 chars). Using "Bitstream Vera Mono Bold Oblique" I was able to verify that this does cause problems with the test case and with Font2DTest for both 32 bit XP and 64bit Windows 2003 server x64. On 32 bit XP the mainfestation is that the font is skipped. On 2004 x64 there is a silent exit. The fix is simple. If the fullname is >=32 chars, skip the check. This means that the intent of 6517861 is simply ignored for fonts that have names > 32 in length but since it was designed to identify cases where windows has family aliases and none of those are likely to involve fonts of such name lengths this should be fine. The size limitations in GDI seem a bit short. Although I don't have any examples of fonts with family names >=32 or full names >=64 I don't see anything in the TrueType spec which indicates such a limit. http://www.microsoft.com/typography/otspec/name.htm Presumably windows either refuses to install such fonts or truncates the length of their names. I'll wait for verification from the submitter that he also has fonts with long names in case there's something more going on.
23-04-2007