bugThe FreeType Project - Bugs: bug #35604, Out-of-bounds read in...

 
 

bug #35604: Out-of-bounds read in gray_record_cell, resulting in potential memory corruption

Submitted by:  Mateusz Jurczyk <j00ru>
Submitted on:  Thu 23 Feb 2012 01:11:43 PM UTC  
 
Severity:  3 - Normal Item Group:  Crash
Status:  Fixed Privacy:  Public
Assigned to:  suzuki toshiya <mpsuzuki> Open/Closed:  Closed
Planned Release:  2.4.9

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Thu 22 Mar 2012 04:31:54 PM UTC, comment #14: 

Thanks.  However, this has absolutely no priority!

Werner LEMBERG <wl>
Project Administrator
Thu 22 Mar 2012 04:18:48 PM UTC, comment #13: 

OK, I will check, please let me spend a few weeks to
restore my 16bit emulation environment.

suzuki toshiya <mpsuzuki>
Project AdministratorIn charge of this item.
Thu 22 Mar 2012 03:39:13 PM UTC, comment #12: 

Mhmm, you are proably right.  It has been a long time that I've checked whether FreeType works and compiles on 16bit hosts.  I suspect many glitches.  Toshiya-san?

Werner LEMBERG <wl>
Project Administrator
Thu 22 Mar 2012 03:19:52 PM UTC, comment #11: 

One nitpick: is it expected that the following overflow check is still #if FT_UINT_MAX > 0xFFFFU ?
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/smooth/ftsmooth.c?id=fcbc82e6#n222

Now with width / height being FT_Pos, I presume it's no longer guaranteed that the maximum value for those variables determined by the type size is less than 0xFFFFU.

Tomas Hoger <thoger>
Sun 26 Feb 2012 09:00:37 PM UTC, comment #10: 

I'm waiting for info from someone at Microsoft to fix #35601 properly.

Werner LEMBERG <wl>
Project Administrator
Sun 26 Feb 2012 08:38:58 PM UTC, comment #9: 

Thanks, works fine now. Do you have any plans as of when version 2.4.9 is going to be officially released?

Mateusz Jurczyk <j00ru>
Project Member
Sun 26 Feb 2012 07:56:06 PM UTC, comment #8: 

Thanks a lot for your detailed analysis.  I've applied a patch following your suggestions.  Please test.

Werner LEMBERG <wl>
Project Administrator
Sun 26 Feb 2012 07:21:55 PM UTC, comment #7: 

I have performed a cursory investigation and I believe I found the bug, as well as the reason it only manifests itself on 64-bit platforms. See below.

First, let's break on the call to FT_Render_Glyph which leads to the SIGSEGV, and investigate the face->glyph structure passed as the "slot" parameter:

--- cut ---
(gdb) where
#0  test_render (timer=0x7fffffffe210, face=0x60a9b0, user_data=<optimized out>) at ft2demos-2.4.8/src/ftbench.c:274
#1  0x0000000000402192 in benchmark (face=0x60a9b0, test=0x7fffffffe290, max_iter=0, max_time=<optimized out>)
    at ft2demos-2.4.8/src/ftbench.c:191
#2  0x000000000040260e in main (argc=<optimized out>, argv=<optimized out>) at ft2demos-2.4.8/src/ftbench.c:874

(gdb) l 
269   {
270     if ( FT_Load_Glyph( face, i, load_flags ) )
271       continue;
272
273     TIMER_START( timer );
274     if ( !FT_Render_Glyph( face->glyph, render_mode ) )
275       done++;
276     TIMER_STOP( timer );
277   }
278

(gdb) print *face->glyph
$3 = {library = 0x605040, face = 0x60a9b0, next = 0x0, reserved = 0, generic = {data = 0x0, finalizer = 0}, metrics = {width = 448, height = 274877907328,
    horiBearingX = 0, horiBearingY = 274877907328, horiAdvance = 512, vertBearingX = -256, vertBearingY = 320, vertAdvance = 640}, linearHoriAdvance = 491200,
  linearVertAdvance = 655360, advance = {x = 512, y = 0}, format = FT_GLYPH_FORMAT_OUTLINE, bitmap = {rows = 0, width = 0, pitch = 0, buffer = 0x0, num_grays = 256,
    pixel_mode = 0 '\000', palette_mode = 0 '\000', palette = 0x0}, bitmap_left = 0, bitmap_top = 0, outline = {n_contours = 2, n_points = 50, points = 0x60f320,
    tags = 0x60d820 "5", contours = 0x610b40, flags = 256}, num_subglyphs = 0, subglyphs = 0x0, control_data = 0x60d5d0, control_len = 164, lsb_delta = 0,
  rsb_delta = 0, other = 0x0, internal = 0x60bd60}

(gdb) print face->glyph->outline->points[0]
$4 = {x = 326, y = 274877907300}
--- cut ---

Please note the very large values of face->glyph->metrics->height (274877907328) and face->glyph->outline->points[0].y (274877907300).

Next then, the execution is recursively passed to the ft_smooth_render_generic routine (src/smooth/ftsmooth.c):

--- cut ---
(gdb) b ft_smooth_render_generic
Breakpoint 2 at 0x7ffff7ba5d61: file freetype2/src/smooth/ftsmooth.c, line 106.
(gdb) c
Continuing.

Breakpoint 2, ft_smooth_render_generic (render=0x60a670, slot=0x60bc20, mode=FT_RENDER_MODE_NORMAL, origin=0x0, required_mode=FT_RENDER_MODE_NORMAL)
    at freetype2/src/smooth/ftsmooth.c:106
106     FT_Outline*  outline = NULL;

(gdb) where
#0  ft_smooth_render_generic (render=0x60a670, slot=0x60bc20, mode=FT_RENDER_MODE_NORMAL, origin=0x0, required_mode=FT_RENDER_MODE_NORMAL)
    at freetype2/src/smooth/ftsmooth.c:106
#1  0x00007ffff7ba6393 in ft_smooth_render (render=0x60a670, slot=0x60bc20, mode=FT_RENDER_MODE_NORMAL, origin=0x0)
    at freetype2/src/smooth/ftsmooth.c:383
#2  0x00007ffff7b3354a in FT_Render_Glyph_Internal (library=0x605040, slot=0x60bc20, render_mode=FT_RENDER_MODE_NORMAL)
    at freetype2/src/base/ftobjs.c:4025
#3  0x00007ffff7b3361f in FT_Render_Glyph (slot=0x60bc20, render_mode=FT_RENDER_MODE_NORMAL) at freetype2/src/base/ftobjs.c:4065
#4  0x0000000000401f33 in test_render (timer=0x7fffffffe210, face=0x60a9b0, user_data=<optimized out>) at ft2demos-2.4.8/src/ftbench.c:274
#5  0x0000000000402192 in benchmark (face=0x60a9b0, test=0x7fffffffe290, max_iter=0, max_time=<optimized out>)
    at ft2demos-2.4.8/src/ftbench.c:191
#6  0x000000000040260e in main (argc=<optimized out>, argv=<optimized out>) at ft2demos-2.4.8/src/ftbench.c:874
--- cut ---

The function proceeds to calculating the glyph height and stores it in a local variable:

--- cut ---
(gdb) n
164       height = (FT_UInt)( ( cbox.yMax - cbox.yMin ) >> 6 );
(gdb) print cbox.yMax
$9 = 274877907328
(gdb) print cbox.yMin
$10 = 0
(gdb) print (cbox.yMax - cbox.yMin) >> 6
$11 = 4294967302
(gdb) print (FT_UInt)((cbox.yMax - cbox.yMin) >> 6)
$12 = 6
(gdb) ptype cbox.yMax
type = long int
(gdb) ptype height
type = unsigned int
--- cut ---

As can be seen, there's an inconsistency between the types of the local variable later use for glyph size sanitization, and the structure fields storing the metrics. This leads to truncation of very large values (> 32bit values) and can result in bypassing the glyph size sanity check. Since the widths of "long int" and "unsigned int" are equal on 32-bit architectures, the problem does not manifest there.

--- cut ---
(gdb) b  freetype2/src/smooth/ftsmooth.c:226
Breakpoint 4 at 0x7ffff7ba6007: file freetype2/src/smooth/ftsmooth.c, line 226.
(gdb) c
Continuing.

Breakpoint 4, ft_smooth_render_generic (render=0x60a670, slot=0x60bc20, mode=FT_RENDER_MODE_NORMAL, origin=0x0, required_mode=FT_RENDER_MODE_NORMAL)
    at freetype2/src/smooth/ftsmooth.c:226
226     if ( width > 0x7FFFU || height > 0x7FFFU )
(gdb) print width
$13 = 7
(gdb) print height
$14 = 6
(gdb) n
235     bitmap->pixel_mode = FT_PIXEL_MODE_GRAY;
--- cut ---

Next, the execution goes down to gray_set_cell, which sets the value of worker->ey to the original face->glyph->outline->points[0].y:

--- cut ---
(gdb) b freetype2/src/smooth/ftgrays.c:561
Breakpoint 5 at 0x7ffff7ba3231: file freetype2/src/smooth/ftgrays.c, line 561.
(gdb) c
Continuing.

Breakpoint 5, gray_set_cell (worker=0x6051c0, ex=5, ey=4294967301) at freetype2/src/smooth/ftgrays.c:561
561     ras.ey      = ey;
(gdb) print ey
$15 = 4294967301
(gdb) where
#0  gray_set_cell (worker=0x6051c0, ex=5, ey=4294967301) at freetype2/src/smooth/ftgrays.c:561
#1  0x00007ffff7ba333a in gray_start_cell (worker=0x6051c0, ex=5, ey=4294967301) at freetype2/src/smooth/ftgrays.c:588
#2  0x00007ffff7ba49b4 in gray_move_to (to=0x7fffffffdb40, worker=0x6051c0) at freetype2/src/smooth/ftgrays.c:1135
#3  0x00007ffff7b34534 in FT_Outline_Decompose (outline=0x6058e8, func_interface=0x7ffff7dda820, user=0x6051c0)
    at freetype2/src/base/ftoutln.c:138
#4  0x00007ffff7ba50b6 in gray_convert_glyph_inner (worker=0x6051c0) at freetype2/src/smooth/ftgrays.c:1717
#5  0x00007ffff7ba5550 in gray_convert_glyph (worker=0x6051c0) at freetype2/src/smooth/ftgrays.c:1819
#6  0x00007ffff7ba5a54 in gray_raster_render (raster=0x60a720, params=0x7fffffffdf90) at freetype2/src/smooth/ftgrays.c:1949
#7  0x00007ffff7ba6115 in ft_smooth_render_generic (render=0x60a670, slot=0x60bc20, mode=FT_RENDER_MODE_NORMAL, origin=0x0, required_mode=FT_RENDER_MODE_NORMAL)
    at freetype2/src/smooth/ftsmooth.c:297
#8  0x00007ffff7ba6393 in ft_smooth_render (render=0x60a670, slot=0x60bc20, mode=FT_RENDER_MODE_NORMAL, origin=0x0)
    at freetype2/src/smooth/ftsmooth.c:383
#9  0x00007ffff7b3354a in FT_Render_Glyph_Internal (library=0x605040, slot=0x60bc20, render_mode=FT_RENDER_MODE_NORMAL)
    at freetype2/src/base/ftobjs.c:4025
#10 0x00007ffff7b3361f in FT_Render_Glyph (slot=0x60bc20, render_mode=FT_RENDER_MODE_NORMAL) at freetype2/src/base/ftobjs.c:4065
#11 0x0000000000401f33 in test_render (timer=0x7fffffffe210, face=0x60a9b0, user_data=<optimized out>) at ft2demos-2.4.8/src/ftbench.c:274
#12 0x0000000000402192 in benchmark (face=0x60a9b0, test=0x7fffffffe290, max_iter=0, max_time=<optimized out>)
    at ft2demos-2.4.8/src/ftbench.c:191
#13 0x000000000040260e in main (argc=<optimized out>, argv=<optimized out>) at ft2demos-2.4.8/src/ftbench.c:874
--- cut ---

Eventually, the gray_find_cell function is called; it uses the just-set worker->ey value as an index to worker->ycells, and since it fails to reference the out-of-bounds address, a SIGSEGV is generated:

--- cut ---
(gdb) b freetype2/src/smooth/ftgrays.c:477
Breakpoint 6 at 0x7ffff7ba301b: file freetype2/src/smooth/ftgrays.c, line 477.
(gdb) c
Continuing.

Breakpoint 6, gray_find_cell (worker=0x6051c0) at freetype2/src/smooth/ftgrays.c:477
477     pcell = &ras.ycells[ras.ey];
(gdb) print worker->ey
$16 = 4294967301
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7ba303e in gray_find_cell (worker=0x6051c0) at freetype2/src/smooth/ftgrays.c:480
480       cell = *pcell;
(gdb) print pcell
$17 = (PCell *) 0x800605b68
(gdb) where
#0  0x00007ffff7ba303e in gray_find_cell (worker=0x6051c0) at freetype2/src/smooth/ftgrays.c:480
#1  0x00007ffff7ba3150 in gray_record_cell (worker=0x6051c0) at freetype2/src/smooth/ftgrays.c:511
#2  0x00007ffff7ba320f in gray_set_cell (worker=0x6051c0, ex=4, ey=5) at freetype2/src/smooth/ftgrays.c:554
#3  0x00007ffff7ba3b26 in gray_render_line (worker=0x6051c0, to_x=1124, to_y=1452) at freetype2/src/smooth/ftgrays.c:814
#4  0x00007ffff7ba418c in gray_render_conic (worker=0x6051c0, control=0x7fffffffdb50, to=0x7fffffffdb20) at freetype2/src/smooth/ftgrays.c:946
#5  0x00007ffff7ba4a49 in gray_conic_to (control=0x7fffffffdb50, to=0x7fffffffdb20, worker=0x6051c0) at freetype2/src/smooth/ftgrays.c:1157
#6  0x00007ffff7b346b3 in FT_Outline_Decompose (outline=0x6058e8, func_interface=0x7ffff7dda820, user=0x6051c0)
    at freetype2/src/base/ftoutln.c:190
#7  0x00007ffff7ba50b6 in gray_convert_glyph_inner (worker=0x6051c0) at freetype2/src/smooth/ftgrays.c:1717
#8  0x00007ffff7ba5550 in gray_convert_glyph (worker=0x6051c0) at freetype2/src/smooth/ftgrays.c:1819
#9  0x00007ffff7ba5a54 in gray_raster_render (raster=0x60a720, params=0x7fffffffdf90) at freetype2/src/smooth/ftgrays.c:1949
#10 0x00007ffff7ba6115 in ft_smooth_render_generic (render=0x60a670, slot=0x60bc20, mode=FT_RENDER_MODE_NORMAL, origin=0x0, required_mode=FT_RENDER_MODE_NORMAL)
    at freetype2/src/smooth/ftsmooth.c:297
#11 0x00007ffff7ba6393 in ft_smooth_render (render=0x60a670, slot=0x60bc20, mode=FT_RENDER_MODE_NORMAL, origin=0x0)
    at freetype2/src/smooth/ftsmooth.c:383
#12 0x00007ffff7b3354a in FT_Render_Glyph_Internal (library=0x605040, slot=0x60bc20, render_mode=FT_RENDER_MODE_NORMAL)
    at freetype2/src/base/ftobjs.c:4025
#13 0x00007ffff7b3361f in FT_Render_Glyph (slot=0x60bc20, render_mode=FT_RENDER_MODE_NORMAL) at freetype2/src/base/ftobjs.c:4065
#14 0x0000000000401f33 in test_render (timer=0x7fffffffe210, face=0x60a9b0, user_data=<optimized out>) at ft2demos-2.4.8/src/ftbench.c:274
#15 0x0000000000402192 in benchmark (face=0x60a9b0, test=0x7fffffffe290, max_iter=0, max_time=<optimized out>)
    at ft2demos-2.4.8/src/ftbench.c:191
#16 0x000000000040260e in main (argc=<optimized out>, argv=<optimized out>) at ft2demos-2.4.8/src/ftbench.c:874
--- cut ---

It appears to me that a sufficient fix would be to change the types of "height", "width", "pitch", "org_height", "org_width" local variables in ft_smooth_render_generic from FT_UInt to FT_Pos (or equivalent), and remove the type casts at lines 154 and 164. After applying such a patch, ftbench doesn't crash anymore:

--- cut ---
==10300== Memcheck, a memory error detector
==10300== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==10300== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info
==10300== Command: ./lt-ftbench tmp/freetype/Umpush.ttf.9f7.205
==10300==
Load                      : 250.017 us/op
Load_Advances (Normal)    : 31.394 us/op
Load_Advances (Fast)      : 0.631 us/op
Render                    : 22029.244 us/op
Get_Glyph                 : 49.401 us/op
Get_CBox                  : 14.452 us/op
Get_Char_Index            : 1.017 us/op
Iterate CMap              : 49845.864 us/op
New_Face                  : 915.805 us/op
Embolden                  : 10.391 us/op
==10300==
==10300== HEAP SUMMARY:
==10300==     in use at exit: 0 bytes in 0 blocks
==10300==   total heap usage: 116,603 allocs, 116,603 frees, 51,093,726 bytes allocated
==10300==
==10300== All heap blocks were freed -- no leaks are possible
==10300==
==10300== For counts of detected and suppressed errors, rerun with: -v
==10300== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
--- cut ---

Mateusz Jurczyk <j00ru>
Project Member
Sun 26 Feb 2012 04:37:11 AM UTC, comment #6: 

Since I don't have access to an amd64 platform, I can't confirm the crash.  I'm really dependent on your assistance...

BTW, I forgot that after

  make devel
  make

you might try to activate debugging output; perhaps this gives additional hints:

  FT2_DEBUG=smooth:7 ftbench...

You might also try `all' instead of `smooth'.  See docs/DEBUG for more details; the FT_COMPONENTS macro in the source files gives other possible values for the debugging output in case you want to trace a different FreeType module.

Werner LEMBERG <wl>
Project Administrator
Fri 24 Feb 2012 12:59:33 PM UTC, comment #5: 

I performed several tests, compiled FreeType with the steps outlined by you etc, but the crash still reproduced (see another valgrind log from the crash from current git below).

However, when I tried the -m32 flag, the crash no longer occured. It therefore seems to only be reproducible when compiled to 64-bit. Can you confirm that the crash occurs on the amd64 architecture?

==3805== Memcheck, a memory error detector
==3805== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==3805== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info
==3805== Command: ./ftbench ~/tmp/freetype/Norasi.dfont.9f7.180
==3805==
tt_face_build_cmaps: broken cmap sub-table ignored
tt_face_build_cmaps: broken cmap sub-table ignored
Load                      : 1194.678 us/op
Load_Advances (Normal)    : 607.639 us/op
Load_Advances (Fast)      : 1.947 us/op
Render                    : ft_smooth_render_generic: glyph too large: yMin = -1, yMax = 1073741824
==3805== Invalid read of size 8
==3805==    at 0x47D2EE: gray_find_cell (freetype2/src/smooth/ftgrays.c:480)
==3805==    by 0x47D3FF: gray_record_cell (freetype2/src/smooth/ftgrays.c:511)
==3805==    by 0x47D4BE: gray_set_cell (freetype2/src/smooth/ftgrays.c:554)
==3805==    by 0x47DBF0: gray_render_line (freetype2/src/smooth/ftgrays.c:769)
==3805==    by 0x47ECC6: gray_line_to (freetype2/src/smooth/ftgrays.c:1147)
==3805==    by 0x40E3D6: FT_Outline_Decompose (freetype2/src/base/ftoutln.c:160)
==3805==    by 0x47F4EA: gray_convert_glyph_inner (freetype2/src/smooth/ftgrays.c:1717)
==3805==    by 0x47F984: gray_convert_glyph (freetype2/src/smooth/ftgrays.c:1819)
==3805==    by 0x47FEA0: gray_raster_render (freetype2/src/smooth/ftgrays.c:1949)
==3805==    by 0x48070D: ft_smooth_render_generic (freetype2/src/smooth/ftsmooth.c:273)
==3805==    by 0x480945: ft_smooth_render (freetype2/src/smooth/ftsmooth.c:383)
==3805==    by 0x40D1A2: FT_Render_Glyph_Internal (freetype2/src/base/ftobjs.c:4025)
==3805==  Address 0x80564acf8 is not stack'd, malloc'd or (recently) free'd
==3805==
==3805==
==3805== Process terminating with default action of signal 11 (SIGSEGV)
==3805==  Access not within mapped region at address 0x80564ACF8
==3805==    at 0x47D2EE: gray_find_cell (freetype2/src/smooth/ftgrays.c:480)
==3805==    by 0x47D3FF: gray_record_cell (freetype2/src/smooth/ftgrays.c:511)
==3805==    by 0x47D4BE: gray_set_cell (freetype2/src/smooth/ftgrays.c:554)
==3805==    by 0x47DBF0: gray_render_line (freetype2/src/smooth/ftgrays.c:769)
==3805==    by 0x47ECC6: gray_line_to (freetype2/src/smooth/ftgrays.c:1147)
==3805==    by 0x40E3D6: FT_Outline_Decompose (freetype2/src/base/ftoutln.c:160)
==3805==    by 0x47F4EA: gray_convert_glyph_inner (freetype2/src/smooth/ftgrays.c:1717)
==3805==    by 0x47F984: gray_convert_glyph (freetype2/src/smooth/ftgrays.c:1819)
==3805==    by 0x47FEA0: gray_raster_render (freetype2/src/smooth/ftgrays.c:1949)
==3805==    by 0x48070D: ft_smooth_render_generic (freetype2/src/smooth/ftsmooth.c:273)
==3805==    by 0x480945: ft_smooth_render (freetype2/src/smooth/ftsmooth.c:383)
==3805==    by 0x40D1A2: FT_Render_Glyph_Internal (freetype2/src/base/ftobjs.c:4025)
==3805==  If you believe this happened as a result of a stack
==3805==  overflow in your program's main thread (unlikely but
==3805==  possible), you can try to increase the size of the
==3805==  main thread stack using the --main-stacksize= flag.
==3805==  The main thread stack size used in this run was 8388608.
==3805==
==3805== HEAP SUMMARY:
==3805==     in use at exit: 155,540 bytes in 76 blocks
==3805==   total heap usage: 2,930 allocs, 2,854 frees, 8,541,745 bytes allocated
==3805==
==3805== LEAK SUMMARY:
==3805==    definitely lost: 0 bytes in 0 blocks
==3805==    indirectly lost: 0 bytes in 0 blocks
==3805==      possibly lost: 0 bytes in 0 blocks
==3805==    still reachable: 155,540 bytes in 76 blocks
==3805==         suppressed: 0 bytes in 0 blocks
==3805== Rerun with --leak-check=full to see details of leaked memory
==3805==
==3805== For counts of detected and suppressed errors, rerun with: -v
==3805== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)

Mateusz Jurczyk <j00ru>
Project Member
Fri 24 Feb 2012 11:34:15 AM UTC, comment #4: 

It's extremely hard to find such a bug if everything's working just fine...

I usually compile and test FreeType with

  make devel
  make

followed by

  make FT2DEMOS=1 -f /path/to/freetype2.compiled/Makefile

to compile the demo programs.

It would be great if you could report the valgrind and/or gdb information of the problem for this kind of build also.

Werner LEMBERG <wl>
Project Administrator
Fri 24 Feb 2012 10:11:55 AM UTC, comment #3: 

Ah, I figured the reason that the crash reproduced in lt-ftbench but not in ftbench was that the former was linked against the latest freetype, and the former against the version present in my OS. It therefore seems the bug must have been introduced recently.

I've also confirmed that the rest of the samples from my recent reports reproduce with the current git, except for #35609 which weirdly only shows up in AddressSanitizer.

Mateusz Jurczyk <j00ru>
Project Member
Fri 24 Feb 2012 09:54:02 AM UTC, comment #2: 

At first, I was testing the public 2.4.8 release. I've just tested both provided sample with the current git of FreeType compiled with ./configure & make with no parameters. Interestingly, the crashes only reproduce with the lt-ftbench binary (bin/.libs/lt-ftbench, created by the /bin/ftbench script), and not with the original ftbench (/bin/.libs/ftbench).

Mateusz Jurczyk <j00ru>
Project Member
Fri 24 Feb 2012 06:02:00 AM UTC, comment #1: 

Interesting.  I can't repeat this on my 32bit i686 GNU/Linux box, using the current git version of FreeType (and valgrind version 3.7.0).  Which FreeType version are you testing?  May I ask you to retry your test with current git?

Werner LEMBERG <wl>
Project Administrator
Thu 23 Feb 2012 01:11:43 PM UTC, original submission:  

Crash tested with ftbench, compiled under Ubuntu amd64 with AddressSanitizer (http://code.google.com/p/address-sanitizer/).

Crashlog:

#0  0x000000000051c7c3 in gray_find_cell ()
#1  0x000000000051c610 in gray_record_cell ()
#2  0x000000000051df98 in gray_set_cell ()
#3  0x000000000051d6d9 in gray_render_line ()
#4  0x000000000051caba in gray_line_to ()
#5  0x000000000049ac6c in FT_Outline_Decompose ()
#6  0x000000000051bbf6 in gray_convert_glyph_inner ()
#7  0x000000000051b132 in gray_convert_glyph ()
#8  0x000000000051984b in ft_smooth_render_generic ()
#9  0x0000000000497c37 in FT_Render_Glyph_Internal ()
#10 0x0000000000486094 in test_render (timer=0x7fffffffdf20, face=0x7ffff6778880, user_data=0x2) at freetype2/ft2demos-2.4.8/src/ftbench.c:274
#11 0x0000000000485b6e in benchmark (face=0x7ffff6778880, test=<optimized out>, max_iter=0, max_time=2) at freetype2/ft2demos-2.4.8/src/ftbench.c:191
#12 0x0000000000488384 in main (argc=<optimized out>, argv=<optimized out>) at freetype2/ft2demos-2.4.8/src/ftbench.c:806

=> 0x51c7c3 <gray_find_cell+195>: mov    rcx,QWORD PTR [rdi]
   0x51c7c6 <gray_find_cell+198>: test   rcx,rcx
   0x51c7c9 <gray_find_cell+201>: je     0x51c7e6 <gray_find_cell+230>
   0x51c7cb <gray_find_cell+203>: mov    rax,rcx
   0x51c7ce <gray_find_cell+206>: shr    rax,0x3

rax            0x1000fec6eb43 17596460493635
rbx            0x100000000000 17592186044416
rcx            0x100000000000 17592186044416
rdx            0x2 2
rsi            0x1000fec6eb43 17596460493635
rdi            0x8007f6375a18 140771683949080
rbp            0x7fffffffcff0 0x7fffffffcff0
rsp            0x7fffffffcfe0 0x7fffffffcfe0
r8             0xffffffffffffffff -1
r9             0x264 612
r10            0x1ffffec6ea19 35184351570457
r11            0xb9 185
r12            0x7ffff63750c0 140737324208320
r13            0x100000000000 17592186044416
r14            0x7ffff6375080 140737324208256
r15            0xffffec6ea19 17592165526041
rip            0x51c7c3 0x51c7c3 <gray_find_cell+195>
eflags         0x10246 [ PF ZF IF RF ]
cs             0x33 51
ss             0x2b 43
ds             0x0 0
es             0x0 0
fs             0x0 0
gs             0x0 0

Log from Valgrind:

==1414== Memcheck, a memory error detector
==1414== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==1414== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info
==1414== Command: ./a.out tmp/freetype/Norasi.dfont.9f7.180
==1414==
Load                      : 368.020 us/op
Load_Advances (Normal)    : 190.741 us/op
Load_Advances (Fast)      : 0.624 us/op
Render                    : ==1414== Invalid read of size 8
==1414==    at 0x44C509: gray_record_cell (freetype2/freetype-2.4.8/src/smooth/ftgrays.c:470)
==1414==    by 0x44CF49: gray_set_cell (freetype2/freetype-2.4.8/src/smooth/ftgrays.c:544)
==1414==    by 0x44D4DC: gray_render_line (freetype2/freetype-2.4.8/src/smooth/ftgrays.c:759)
==1414==    by 0x44DC9D: gray_line_to (freetype2/freetype-2.4.8/src/smooth/ftgrays.c:1136)
==1414==    by 0x40517D: FT_Outline_Decompose (freetype2/freetype-2.4.8/src/base/ftoutln.c:160)
==1414==    by 0x44C5F2: gray_convert_glyph_inner (freetype2/freetype-2.4.8/src/smooth/ftgrays.c:1706)
==1414==    by 0x44C99A: gray_convert_glyph (freetype2/freetype-2.4.8/src/smooth/ftgrays.c:1808)
==1414==    by 0x44C175: ft_smooth_render_generic (freetype2/freetype-2.4.8/src/smooth/ftsmooth.c:297)
==1414==    by 0x404A38: FT_Render_Glyph_Internal (freetype2/freetype-2.4.8/src/base/ftobjs.c:4021)
==1414==    by 0x401962: test_render (freetype2/ft2demos-2.4.8/src/ftbench.c:274)
==1414==    by 0x4016FC: benchmark (freetype2/ft2demos-2.4.8/src/ftbench.c:191)
==1414==    by 0x4028C6: main (freetype2/ft2demos-2.4.8/src/ftbench.c:825)
==1414==  Address 0x8053cdce8 is not stack'd, malloc'd or (recently) free'd
==1414==
==1414==
==1414== Process terminating with default action of signal 11 (SIGSEGV)
==1414==  Access not within mapped region at address 0x8053CDCE8
==1414==    at 0x44C509: gray_record_cell (freetype2/freetype-2.4.8/src/smooth/ftgrays.c:470)
==1414==    by 0x44CF49: gray_set_cell (freetype2/freetype-2.4.8/src/smooth/ftgrays.c:544)
==1414==    by 0x44D4DC: gray_render_line (freetype2/freetype-2.4.8/src/smooth/ftgrays.c:759)
==1414==    by 0x44DC9D: gray_line_to (freetype2/freetype-2.4.8/src/smooth/ftgrays.c:1136)
==1414==    by 0x40517D: FT_Outline_Decompose (freetype2/freetype-2.4.8/src/base/ftoutln.c:160)
==1414==    by 0x44C5F2: gray_convert_glyph_inner (freetype2/freetype-2.4.8/src/smooth/ftgrays.c:1706)
==1414==    by 0x44C99A: gray_convert_glyph (freetype2/freetype-2.4.8/src/smooth/ftgrays.c:1808)
==1414==    by 0x44C175: ft_smooth_render_generic (freetype2/freetype-2.4.8/src/smooth/ftsmooth.c:297)
==1414==    by 0x404A38: FT_Render_Glyph_Internal (freetype2/freetype-2.4.8/src/base/ftobjs.c:4021)
==1414==    by 0x401962: test_render (freetype2/ft2demos-2.4.8/src/ftbench.c:274)
==1414==    by 0x4016FC: benchmark (freetype2/ft2demos-2.4.8/src/ftbench.c:191)
==1414==    by 0x4028C6: main (freetype2/ft2demos-2.4.8/src/ftbench.c:825)
==1414==  If you believe this happened as a result of a stack
==1414==  overflow in your program's main thread (unlikely but
==1414==  possible), you can try to increase the size of the
==1414==  main thread stack using the --main-stacksize= flag.
==1414==  The main thread stack size used in this run was 8388608.
==1414==
==1414== HEAP SUMMARY:
==1414==     in use at exit: 154,108 bytes in 76 blocks
==1414==   total heap usage: 8,476 allocs, 8,400 frees, 26,056,447 bytes allocated
==1414==
==1414== LEAK SUMMARY:
==1414==    definitely lost: 0 bytes in 0 blocks
==1414==    indirectly lost: 0 bytes in 0 blocks
==1414==      possibly lost: 0 bytes in 0 blocks
==1414==    still reachable: 154,108 bytes in 76 blocks
==1414==         suppressed: 0 bytes in 0 blocks
==1414== Rerun with --leak-check=full to see details of leaked memory
==1414==
==1414== For counts of detected and suppressed errors, rerun with: -v
==1414== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)

Mateusz Jurczyk <j00ru>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #25142:  Umpush.ttf.9f7.205 added by j00ru (68KiB - application/octet-stream - A testcase of the same issue, with a different callstack.)
file #25141:  Norasi.dfont.9f7.180 added by j00ru (106KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mpsuzuki (Posted a comment)
  • -email is unavailable- added by wl
  • -email is unavailable- added by thoger (Posted a comment)
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by j00ru (Submitted the item)
  • -email is unavailable- added by j00ru
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-03-22 mpsuzuki Assigned towl => mpsuzuki
    2012-03-22 wl Carbon-Copy- => Added mpsuzuki
    2012-02-26 wl StatusNone => Fixed
        PrivacyPrivate => Public
        Open/ClosedOpen => Closed
        Planned ReleaseNone => 2.4.9
    2012-02-25 wl Assigned toNone => wl
    2012-02-23 j00ru Attached File- => Added Umpush.ttf.9f7.205, #25142
    2012-02-23 j00ru Attached File- => Added Norasi.dfont.9f7.180, #25141
        Carbon-Copy- => Added j00ru

    Back to the top


    Powered by Savane 3.5