[Bug 42243] New: 3DMark11 installer crashes with access violation in Freetype because font data is released too early

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=42243

            Bug ID: 42243
           Summary: 3DMark11 installer crashes with access violation in
                    Freetype because font data is released too early
           Product: Wine
           Version: 2.0-rc5
          Hardware: x86
               URL: https://ftp.computerbase.de/dl-856/UeQSx5zAJUXrxV_B1iD
                    Xuw/1484758851/3DMark11-v1-0-132.zip
                OS: Linux
            Status: NEW
          Keywords: download
          Severity: normal
          Priority: P2
         Component: dwrite
          Assignee: wine-bugs at winehq.org
          Reporter: sebastian at fds-team.de
                CC: bunglehead at gmail.com
      Distribution: ---

The installer needs a Wine prefix with dotnet40 and Windows version set to
Windows 7. On one of my machines everything works as expected, on the other one
I'm getting an access violation in Freetype. Relevant lines from the terminal
output:

--- snip ---
003a:trace:dwrite:init_freetype FreeType version is 2.6.3
[...]
003a:trace:dwrite:dwritefontface_GetGdiCompatibleGlyphMetrics
(0x101499f8)->(15.00 1.00 (nil) 0 0x11fb140 8 0x11fb15c 0)
003a:trace:dwrite:dwritefontface_GetDesignGlyphMetrics (0x101499f8)->(0x11fb140
1 0x438c9d4 0)
003a:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7db2a994
ip=7db2a994 tid=003a
003a:trace:seh:raise_exception  info[0]=00000000
003a:trace:seh:raise_exception  info[1]=0204d620
003a:trace:seh:raise_exception  eax=0204d620 ebx=00000173 ecx=7dbb8000
edx=00000000 esi=7db7f840 edi=7db27800
003a:trace:seh:raise_exception  ebp=7cccc420 esp=0438c530 cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00210207
[...]
wine: Unhandled page fault on read access to 0x0204d620 at address 0x7db2a994
(thread 003a), starting debugger...
[...]
Backtrace:
=>0 0x7db2a994 TT_RunIns+0xf4() in libfreetype.so.6 (0x7cccc420)
  1 0x7db2de84 in libfreetype.so.6 (+0x28e83) (0x0438c6a4)
  2 0x7db2dfb4 in libfreetype.so.6 (+0x28fb3) (0x7cc867a0)
  3 0x7db17c58 FT_Load_Glyph+0x187() in libfreetype.so.6 (0x0438c7e8)
  4 0x7db684e6 in libfreetype.so.6 (+0x634e5) (0x7cc91be0)
  5 0x7db6827f in libfreetype.so.6 (+0x6327e) (0x7cc00ee0)
  6 0x7db67984 in libfreetype.so.6 (+0x62983) (0x7cc9b448)
  7 0x7db692bb FTC_ImageCache_Lookup+0x21a() in libfreetype.so.6 (0x7cc9b448)
  8 0x7cf4f18b freetype_get_glyph_advance+0x91(fontface=0x101499f8,
emSize=15.000000, index=0x26, mode=DWRITE_MEASURING_MODE_GDI_CLASSIC)
[.../dlls/dwrite/freetype.c:798] in dwrite (0x0438c9a8)
--- snip ---

Further debugging revealed that the actual problem is in face_requester(). The
memory address lies within a range previously passed to FT_New_Memory_Face.

--- snip ---
    hr = IDWriteFontFileStream_ReadFileFragment(stream, &data_ptr, 0,
data_size, &context);
    if (FAILED(hr)) {
        fterror = FT_Err_Invalid_Stream_Read;
        goto fail;
    }

    index = IDWriteFontFace_GetIndex(fontface);
    fterror = pFT_New_Memory_Face(library, data_ptr, data_size, index, face);
    IDWriteFontFileStream_ReleaseFileFragment(stream, context);
--- snip ---

The file fragment is released immediately after creating the new font face,
which should not be a problem for the builtin implementation. In this case
however it seems that the application is using its own implementation which
deallocates memory in ReleaseFileFragment. The freetype docs say: """You must
not deallocate the memory before calling FT_Done_Face."""

Commenting out the line with IDWriteFontFileStream_ReleaseFileFragment fixes
the crash.

$ sha256sum 3DMark11-v1-0-132.zip 
0a375c6b024deddf3f805ec26a308eaa6b1f6a4f898fe972407d40dcee4ca078 
3DMark11-v1-0-132.zip

Tested with Wine version 2.0-rc5.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.