bugThe FreeType Project - Bugs: bug #30798, User-controllable read (resulting...

 
 

bug #30798: User-controllable read (resulting in SEGV) in smooth/ftgrays.c:472

Submitted by:  Robert Swiecki <jagger>
Submitted on:  Tue 17 Aug 2010 04:04:43 PM UTC  
 
Severity: 3 - NormalItem Group: Crash
Status: FixedPrivacy: Public
Assigned to: suzuki toshiya <mpsuzuki>Open/Closed: Closed
Planned Release: 2.4.3

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 Jump to the original submission)

Wed 01 Sep 2010 12:21:18 AM UTC, comment #21:

Thanks! Here I close this bug.

suzuki toshiya <mpsuzuki>
Project AdministratorIn charge of this item.
Tue 31 Aug 2010 07:15:31 PM UTC, comment #20:

Looks good. Thanks.

Robert Swiecki <jagger>
Mon 30 Aug 2010 04:44:17 PM UTC, comment #19:

I revised my patch to avoid the memory leak
(before unsetting flags, the buffers allocated
during the interpretation are freed).

Attached is revised, and it is already committed
to GIT head. Robert, please test.

(file #21355)

suzuki toshiya <mpsuzuki>
Project AdministratorIn charge of this item.
Mon 30 Aug 2010 01:48:16 PM UTC, comment #18:

This looks OK to me. Thanks for fixing!

Werner LEMBERG <wl>
Project Administrator
Mon 30 Aug 2010 01:18:19 PM UTC, comment #17:

Attached is a patch to unset FT_Face->size->cvt_ready
and FT_Face->size->bytecode_ready (and prevent the
reuse of broken function definitions after the error).
Because it unsets the flags only and does not free the
buffer for bytecode, it has leaking issue, but it prevents
SEGV.

(file #21352)

suzuki toshiya <mpsuzuki>
Project AdministratorIn charge of this item.
Mon 30 Aug 2010 12:32:26 PM UTC, comment #16:

Checking the glyph program execution for glyph 280, after
the function definition broken by glyph 128, I found that
TT_RunIns() for glyph 280 returns an error TT_Err_Stack_Overflow.
But, it is catched by TT_Hint_Glyph() as following:
------------------------------------------------
error = TT_Run_Context( loader->exec, debug );
if ( error && loader->exec->pedantic_hinting )
return error;

/* store drop-out mode in bits 5-7; set bit 2 also as a marker */
current_outline.tags[0] |=
( loader->exec->GS.scan_type << 5 ) | FT_CURVE_TAG_HAS_SCANMODE;
}
------------------------------------------------
So, if pedanting_hinting is NOT set, ANY error is ignored.
is it possible to restrict the kind of error which FT2 can
ignore & proceed?

suzuki toshiya <mpsuzuki>
Project AdministratorIn charge of this item.
Mon 30 Aug 2010 12:24:47 PM UTC, comment #15:

In the glyph program execution for glyph 128, an error
occurs.

Breakpoint 3, load_truetype_glyph (loader=0x7fff53ada790, glyph_index=128, recurse_count=0, header_only=0 '\0') at /home/sssa/redhat/BUILD/freetype2-current/freetype2/src/truetype/ttgload.c:1236
1236 FT_Error error = TT_Err_Ok;
(gdb) c
Continuing.

Breakpoint 9, SkipCode (exc=0x6bf350) at /home/sssa/redhat/BUILD/freetype2-current/freetype2/src/truetype/ttinterp.c:4453
4453 CUR.error = TT_Err_Code_Overflow;
(gdb) where
#0 SkipCode (exc=0x6bf350) at /home/sssa/redhat/BUILD/freetype2-current/freetype2/src/truetype/ttinterp.c:4453
#1 0x000000000041cf06 in Ins_FDEF (exc=0x6bf350, args=0x6c2720) at /home/sssa/redhat/BUILD/freetype2-current/freetype2/src/truetype/ttinterp.c:4602
#2 0x0000000000422648 in TT_RunIns (exc=0x6bf350) at /home/sssa/redhat/BUILD/freetype2-current/freetype2/src/truetype/ttinterp.c:7694
#3 0x000000000041b20d in TT_Run_Context (exec=0x6bf350, debug=0 '\0') at /home/sssa/redhat/BUILD/freetype2-current/freetype2/src/truetype/ttinterp.c:743
#4 0x0000000000416218 in TT_Hint_Glyph (loader=0x7fff53ada790, is_composite=0 '\0') at /home/sssa/redhat/BUILD/freetype2-current/freetype2/src/truetype/ttgload.c:816
#5 0x00000000004167c8 in TT_Process_Simple_Glyph (loader=0x7fff53ada790) at /home/sssa/redhat/BUILD/freetype2-current/freetype2/src/truetype/ttgload.c:937
#6 0x00000000004177ec in load_truetype_glyph (loader=0x7fff53ada790, glyph_index=128, recurse_count=0, header_only=0 '\0')
at /home/sssa/redhat/BUILD/freetype2-current/freetype2/src/truetype/ttgload.c:1426
#7 0x0000000000418ba8 in TT_Load_Glyph (size=0x6c1e80, glyph=0x6c1c30, glyph_index=128, load_flags=0) at /home/sssa/redhat/BUILD/freetype2-current/freetype2/src/truetype/ttgload.c:2079
#8 0x0000000000413ac0 in Load_Glyph (ttslot=0x6c1c30, ttsize=0x6c1e80, glyph_index=128, load_flags=0) at /home/sssa/redhat/BUILD/freetype2-current/freetype2/src/truetype/ttdriver.c:334
#9 0x000000000040710d in FT_Load_Glyph (face=0x6c0a70, glyph_index=128, load_flags=0) at /home/sssa/redhat/BUILD/freetype2-current/freetype2/src/base/ftobjs.c:677
#10 0x00000000004018cc in test_render (timer=0x7fff53adaab0, face=0x6c0a70, user_data=0x0) at /home/sssa/redhat/BUILD/freetype2-current/freetype2-demos/src/ftbench.c:293
#11 0x00000000004015ff in benchmark (face=0x6c0a70, test=0x7fff53adab20, max_iter=1, max_time=2) at /home/sssa/redhat/BUILD/freetype2-current/freetype2-demos/src/ftbench.c:191
#12 0x00000000004027d6 in main (argc=1, argv=0x7fff53adaca0) at /home/sssa/redhat/BUILD/freetype2-current/freetype2-demos/src/ftbench.c:849
(gdb)

The crash scenario seems to be following:

1) The glyph program for glyph 128 is broken.
Its FDEF (function definition) instruction makes
TrueType exec context is garbled. CUR.FDefs
is broken, and face->size->function_defs is broken
too. Ins_FDEF returns overflow error, but (at
least) ftbench does not care about it. The broken
face->size->function_defs are preserved to
passed to next process.

2) The glyph program for glyph 280 uses
the functions in fpgm & prep. But CUR.FDefs
defined by face->size->function_defs is already
broken, and the glyph program for glyph 280
tries to use it.

I think the fallback for 1) is required for first
(e.g. if glyph program execution has error,
cvt_ready & bytecode_ready should be cleared
to prevent unexpected reference of possible
broken values).

In addition, I should investigate more about
2). If face->size->function_defs is broken,
an error should be returned, it should not
cause SEGV.

suzuki toshiya <mpsuzuki>
Project AdministratorIn charge of this item.
Mon 30 Aug 2010 09:15:18 AM UTC, comment #14:

If FT_Size in glyph program execution is initialized
for each glyph rendering, SEGV disappears. I guess
the bad value is stored in there.

The attached patch is NOT to fix this bug, it is for
debug.

(file #21350)

suzuki toshiya <mpsuzuki>
Project AdministratorIn charge of this item.
Mon 30 Aug 2010 06:26:26 AM UTC, comment #13:

If I exchange the order of the glyph program execution from
128-then-280 to 280-then-128, SEGV disappears. In addition,
even if reversal order case (280-then-128), when the benchmark
is executed twice (ftbench -c 2 ...), SEGV @ glyph 280 comes
back.

It seems that both of glyph 128 & 280 require the execution
of program in fpgm & prep table (so, TT_RunIns() is invoked
3 times: for fpgm, for prep, and for glyf entry), and the result
of fpgm & prep execution might be cached. Thus, the program
executed for glyph 280 after glyph 128 is different from that
executed for glyph 280 before glyph 128.

suzuki toshiya <mpsuzuki>
Project AdministratorIn charge of this item.
Mon 30 Aug 2010 03:09:37 AM UTC, comment #12:

You don't have to say sorry, I must thank your great works
finding so many bugs.

suzuki toshiya <mpsuzuki>
Project AdministratorIn charge of this item.
Sun 29 Aug 2010 08:46:34 PM UTC, comment #11:

Sorry, was away for some time. Thanks Suzuki for looking into this. If you'd become stuck with something, let me know, I'll try to help with debugging.

Robert Swiecki <jagger>
Sun 29 Aug 2010 05:04:42 PM UTC, comment #10:

Reproduced on Mac OS X 10.6 on amd64 too,
with same behaviour (glyph 128 + 280, different
glyph program).

suzuki toshiya <mpsuzuki>
Project AdministratorIn charge of this item.
Sun 29 Aug 2010 07:07:31 AM UTC, comment #9:

Comparing the TrueType glyph program execution
in the case "glyph 128 & 280 are drawn" (SEGV)
versus "only glyph 280 is drawn" (no SEGV), the
progam executed for glyph 280 is different. Of course,
in the case "glyph 129 & 280 are drawn" (no SEGV),
the glyph program is same with that in the case
"only glyph 280 is drawn" (no SEGV).

no SEGV case
-------------------------------------------
Glyph 280
# of contours: 2
xMin: 178 xMax: 1654
yMin: 0 yMax: 1515
Instructions size: 393
SVTCA y
PushB[2]
CALL
PushB[0]
SZP0
MPPEM
PushB[0]
LT
IF
...
------------------------------------------

SEGV case
------------------------------------------
Glyph 280
# of contours: 2
xMin: 178 xMax: 1654
yMin: 0 yMax: 1515
Instructions size: 393
SVTCA y
PushB[2]
CALL
UTP
SHP[1]
PushB[1]
MIRP[09]
PushB[0]
SHP[0]
PushB[2]
CALL
UTP
SHP[1]
PushB[1]
MIRP[09]
PushB[0]
SHP[0]
PushB[2]
CALL
UTP
...
------------------------------------------

suzuki toshiya <mpsuzuki>
Project AdministratorIn charge of this item.
Sun 29 Aug 2010 04:47:49 AM UTC, comment #8:

After the test by loop shrinking, the minimum loop I got is following:
---------------------------------------
for ( i = 0; i < face->num_glyphs; i++ )
{
if ( 128 != i && 280 != i )
continue;
---------------------------------------
It seems that rendering only glyph 128 & 280 can cause SEGV.

suzuki toshiya <mpsuzuki>
Project AdministratorIn charge of this item.
Sun 29 Aug 2010 03:06:44 AM UTC, comment #7:

In my testing environment, SEGV occurs when
glyph 280 is rendered. But, if I shrink the loop
in test_render from
----------------------------------------
test_render( btimer_t* timer,
FT_Face face,
void* user_data )
{
int i, done = 0;

FT_UNUSED( user_data );

for ( i = 0; i < face->num_glyphs; i++ )
----------------------------------------
to
----------------------------------------
for ( i = 129; i < face->num_glyphs; i++ )
----------------------------------------
the SEGV does not occur.

The SEGV still occurs in following case.
----------------------------------------
for ( i = 128; i < face->num_glyphs; i++ )
----------------------------------------

I guess the cause of SEGV is created before
the rendering the glyph that ftbench is crashed.

suzuki toshiya <mpsuzuki>
Project AdministratorIn charge of this item.
Sat 28 Aug 2010 09:51:00 PM UTC, comment #6:

I could reproduce this issue on GNU/Linux on amd64
(could not reproduce on GNU/Linux on i386 yet).
I will try to fix this.

(gdb) run -c 1 sigsegv32.ttf
Starting program: /home1/mpsuzuki/redhat/BUILD/ft2demos-2.4.2/bin/ftbench -c 1 sigsegv32.ttf
Load : 45.311 us/op
Load_Advances (Normal) : 22.330 us/op
Load_Advances (Fast) : 0.089 us/op
Render :
Program received signal SIGSEGV, Segmentation fault.
0x000000000046bcee in gray_find_cell (worker=0x6a41d0)
at /home1/mpsuzuki/redhat/BUILD/freetype-2.4.2/src/smooth/ftgrays.c:472
472 cell = *pcell;
(gdb) where
#0 0x000000000046bcee in gray_find_cell (worker=0x6a41d0)
at /home1/mpsuzuki/redhat/BUILD/freetype-2.4.2/src/smooth/ftgrays.c:472
#1 0x000000000046bdf9 in gray_record_cell (worker=0x6a41d0)
at /home1/mpsuzuki/redhat/BUILD/freetype-2.4.2/src/smooth/ftgrays.c:503
#2 0x000000000046beb5 in gray_set_cell (worker=0x6a41d0, ex=5, ey=5)
at /home1/mpsuzuki/redhat/BUILD/freetype-2.4.2/src/smooth/ftgrays.c:546
#3 0x000000000046c761 in gray_render_line (worker=0x6a41d0, to_x=1380,
to_y=1452)
at /home1/mpsuzuki/redhat/BUILD/freetype-2.4.2/src/smooth/ftgrays.c:806
#4 0x000000000046cc2f in gray_render_conic (worker=0x6a41d0,
control=0x7fffffffdbb0, to=0x7fffffffdb80)
at /home1/mpsuzuki/redhat/BUILD/freetype-2.4.2/src/smooth/ftgrays.c:913
#5 0x000000000046d7ca in gray_conic_to (control=0x7fffffffdbb0,
to=0x7fffffffdb80, worker=0x6a41d0)
at /home1/mpsuzuki/redhat/BUILD/freetype-2.4.2/src/smooth/ftgrays.c:1164
#6 0x000000000040b479 in FT_Outline_Decompose (outline=0x6a48f8,
func_interface=0x485560, user=0x6a41d0)
at /home1/mpsuzuki/redhat/BUILD/freetype-2.4.2/src/base/ftoutln.c:190
#7 0x000000000046ddd5 in gray_convert_glyph_inner (worker=0x6a41d0)
at /home1/mpsuzuki/redhat/BUILD/freetype-2.4.2/src/smooth/ftgrays.c:1724
#8 0x000000000046e369 in gray_convert_glyph (worker=0x6a41d0)
at /home1/mpsuzuki/redhat/BUILD/freetype-2.4.2/src/smooth/ftgrays.c:1845
#9 0x000000000046e8b1 in gray_raster_render (raster=0x6a97a0,
params=0x7fffffffe000)
at /home1/mpsuzuki/redhat/BUILD/freetype-2.4.2/src/smooth/ftgrays.c:1975
#10 0x000000000046eefe in ft_smooth_render_generic (render=0x6a96e0,
slot=0x6aac30, mode=FT_RENDER_MODE_NORMAL, origin=0x0,
required_mode=FT_RENDER_MODE_NORMAL)
at /home1/mpsuzuki/redhat/BUILD/freetype-2.4.2/src/smooth/ftsmooth.c:274
#11 0x000000000046f13d in ft_smooth_render (render=0x6a96e0, slot=0x6aac30,
mode=FT_RENDER_MODE_NORMAL, origin=0x0)
at /home1/mpsuzuki/redhat/BUILD/freetype-2.4.2/src/smooth/ftsmooth.c:360
#12 0x000000000040a3b7 in FT_Render_Glyph_Internal (library=0x6a4040,
slot=0x6aac30, render_mode=FT_RENDER_MODE_NORMAL)
at /home1/mpsuzuki/redhat/BUILD/freetype-2.4.2/src/base/ftobjs.c:3914
#13 0x000000000040a471 in FT_Render_Glyph (slot=0x6aac30,
render_mode=FT_RENDER_MODE_NORMAL)
at /home1/mpsuzuki/redhat/BUILD/freetype-2.4.2/src/base/ftobjs.c:3954
#14 0x000000000040173a in test_render (timer=0x7fffffffe280, face=0x6a9a70,
user_data=0x0)
at /home1/mpsuzuki/redhat/BUILD/ft2demos-2.4.2/src/ftbench.c:270
#15 0x00000000004014d5 in benchmark (face=0x6a9a70, test=0x7fffffffe2f0,
max_iter=1, max_time=2)
at /home1/mpsuzuki/redhat/BUILD/ft2demos-2.4.2/src/ftbench.c:189
#16 0x0000000000402686 in main (argc=1, argv=0x7fffffffe460)
at /home1/mpsuzuki/redhat/BUILD/ft2demos-2.4.2/src/ftbench.c:813
(gdb) p/x worker->ey
$1 = 0x100000005

suzuki toshiya <mpsuzuki>
Project AdministratorIn charge of this item.
Sat 21 Aug 2010 07:07:38 AM UTC, comment #5:

Unfortunately, it doesn't help enough: I need the place where `worker->ey' gets set, since the overflow must happen there obviously.

If you can afford some time I would be glad if you did some debugging.

Werner LEMBERG <wl>
Project Administrator
Wed 18 Aug 2010 03:08:04 PM UTC, comment #4:

Also.

ey = 4294967301 = 2^32 + 5

looks like some kind of integer overflow to me.

Robert Swiecki <jagger>
Wed 18 Aug 2010 11:59:41 AM UTC, comment #3:

Here's also valgrind output, but it doesn't add much

$ valgrind ./ftbench -c 1 SIGSEGV.PC.0x46e54e.CODE.1.ADDR.0x8006a8b78.INSTR.mov_rax\,_\[rax\].ttf
==24655== Memcheck, a memory error detector
==24655== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==24655== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==24655== Command: ./ftbench -c 1 SIGSEGV.PC.0x46e54e.CODE.1.ADDR.0x8006a8b78.INSTR.mov_rax,_[rax].ttf
==24655==
Load : 1441.464 us/op
Load_Advances (Normal) : 323.983 us/op
Load_Advances (Fast) : 10.504 us/op
Render : ==24655== Invalid read of size 8
==24655== at 0x46E586: gray_find_cell (ftgrays.c:472)
==24655== by 0x46E697: gray_record_cell (ftgrays.c:503)
==24655== by 0x46E756: gray_set_cell (ftgrays.c:546)
==24655== by 0x46F06D: gray_render_line (ftgrays.c:806)
==24655== by 0x46F538: gray_render_conic (ftgrays.c:913)
==24655== by 0x470116: gray_conic_to (ftgrays.c:1164)
==24655== by 0x40BB33: FT_Outline_Decompose (ftoutln.c:190)
==24655== by 0x470765: gray_convert_glyph_inner (ftgrays.c:1724)
==24655== by 0x470CB6: gray_convert_glyph (ftgrays.c:1845)
==24655== by 0x4711B8: gray_raster_render (ftgrays.c:1975)
==24655== by 0x47187C: ft_smooth_render_generic (ftsmooth.c:292)
==24655== by 0x471AFA: ft_smooth_render (ftsmooth.c:378)
==24655== Address 0x8053c8c08 is not stack'd, malloc'd or (recently) free'd
==24655==
==24655==
==24655== Process terminating with default action of signal 11 (SIGSEGV)
==24655== Access not within mapped region at address 0x8053C8C08
==24655== at 0x46E586: gray_find_cell (ftgrays.c:472)
==24655== by 0x46E697: gray_record_cell (ftgrays.c:503)
==24655== by 0x46E756: gray_set_cell (ftgrays.c:546)
==24655== by 0x46F06D: gray_render_line (ftgrays.c:806)
==24655== by 0x46F538: gray_render_conic (ftgrays.c:913)
==24655== by 0x470116: gray_conic_to (ftgrays.c:1164)
==24655== by 0x40BB33: FT_Outline_Decompose (ftoutln.c:190)
==24655== by 0x470765: gray_convert_glyph_inner (ftgrays.c:1724)
==24655== by 0x470CB6: gray_convert_glyph (ftgrays.c:1845)
==24655== by 0x4711B8: gray_raster_render (ftgrays.c:1975)
==24655== by 0x47187C: ft_smooth_render_generic (ftsmooth.c:292)
==24655== by 0x471AFA: ft_smooth_render (ftsmooth.c:378)
==24655== If you believe this happened as a result of a stack
==24655== overflow in your program's main thread (unlikely but
==24655== possible), you can try to increase the size of the
==24655== main thread stack using the --main-stacksize= flag.
==24655== The main thread stack size used in this run was 8388608.
==24655==
==24655== HEAP SUMMARY:
==24655== in use at exit: 41,228 bytes in 74 blocks
==24655== total heap usage: 361 allocs, 287 frees, 523,498 bytes allocated
==24655==
==24655== LEAK SUMMARY:
==24655== definitely lost: 0 bytes in 0 blocks
==24655== indirectly lost: 0 bytes in 0 blocks
==24655== possibly lost: 0 bytes in 0 blocks
==24655== still reachable: 41,228 bytes in 74 blocks
==24655== suppressed: 0 bytes in 0 blocks
==24655== Rerun with --leak-check=full to see details of leaked memory
==24655==
==24655== For counts of detected and suppressed errors, rerun with: -v
==24655== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
Segmentation fault

Robert Swiecki <jagger>
Wed 18 Aug 2010 11:57:53 AM UTC, comment #2:

$ gdb ./ftbench
(gdb) r -c 1 SIGSEGV.PC.0x46e54e.CODE.1.ADDR.0x8006a8b78.INSTR.mov_rax,_[rax].ttf

Program received signal SIGSEGV, Segmentation fault.
0x000000000046e586 in gray_find_cell (worker=0x6a81d0) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:472
472 cell = *pcell;

(gdb) up
#1 0x000000000046e698 in gray_record_cell (worker=0x6a81d0) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:503
503 PCell cell = gray_find_cell( RAS_VAR );
(gdb) up
#2 0x000000000046e757 in gray_set_cell (worker=0x6a81d0, ex=5, ey=5) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:546
546 gray_record_cell( RAS_VAR );
(gdb) up
#3 0x000000000046f06e in gray_render_line (worker=0x6a81d0, to_x=1380, to_y=1452) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:806
806 gray_set_cell( RAS_VAR_ TRUNC( x ), ey1 );

(gdb) info locals
ey1 = 5
ey2 = 5
fy1 = 20
fy2 = 172
mod = 88
dx = -32
dy = 104
x = 1405
x2 = 25
p = -640
first = 0
delta = -7
rem = 0
lift = 1073741824
incr = -1

(gdb) print *worker
$11 = {ex = 6, ey = 4294967301, min_ex = 0, max_ex = 9, min_ey = 0, max_ey = 6, count_ex = 9, count_ey = 6, area = -5140, cover = -20, invalid = 0, cells = 0x6a8b90, max_cells = 434, num_cells = 0, cx = 0, cy = 0, x = 1412, y = 1556,
last_ey = 1536, bez_stack = {{x = 1460, y = 1628}, {x = 1520, y = 1684}, {x = 1600, y = 1099511629200}, {x = 620, y = 438}, {x = 632, y = 496}, {x = 530, y = 1440}, {x = 584, y = 1440}, {x = 763, y = 3631}, {x = 768, y = 3636}, {
x = 2319, y = 128644}, {x = 2320, y = 128644}, {x = 321, y = 2309453}, {x = 320, y = 2346698}, {x = 320, y = 2365320}, {x = 320, y = 2384090}, {x = 320, y = 2402861}, {x = 320, y = 2421780}, {x = 0, y = 0} <repeats 80 times>},
lev_stack = {18, 1, 1, 1, 1, 2, 1, 1, 0 <repeats 24 times>}, outline = {n_contours = 2, n_points = 50, points = 0x6b02a0, tags = 0x6b0fc0 "5", contours = 0x6b0270, flags = 256}, target = {rows = 6, width = 9, pitch = 9,
buffer = 0x6b0db0 "", num_grays = 256, pixel_mode = 2 '\002', palette_mode = 0 '\000', palette = 0x0}, clip_box = {xMin = 0, yMin = 0, xMax = 9, yMax = 6}, gray_spans = {{x = 2, len = 1, coverage = 10 '\n'}, {x = 3, len = 1,
coverage = 82 'R'}, {x = 4, len = 1, coverage = 89 'Y'}, {x = 5, len = 1, coverage = 21 '\025'}, {x = 5, len = 1, coverage = 77 'M'}, {x = 5, len = 1, coverage = 1 '\001'}, {x = 6, len = 1, coverage = 13 '\r'}, {x = 8, len = 1,
coverage = 103 'g'}, {x = 10, len = 1, coverage = 7 '\a'}, {x = 11, len = 1, coverage = 35 '#'}, {x = 12, len = 1, coverage = 1 '\001'}, {x = 11, len = 1, coverage = 154 '\232'}, {x = 12, len = 1, coverage = 151 '\227'}, {x = 0,
len = 0, coverage = 0 '\000'} <repeats 19 times>}, num_gray_spans = 0, render_span = 0x47015e <gray_render_span>, render_span_data = 0x6a81d0, span_y = 7, band_size = 54, band_shoot = 0, conic_level = 32, cubic_level = 16,
jump_buffer = {{__jmpbuf = {274877907328, 4605452385232364809, 4199616, 140737488348672, 0, 0, 4605452385236559113, -4605451810694093559}, __mask_was_saved = 0, __saved_mask = {__val = {0 <repeats 16 times>}}}}, buffer = 0x6a8b50,
buffer_size = 13952, ycells = 0x6a8b50, ycount = 6}

Hope this helps, if not, I'll dive into debugging

Robert Swiecki <jagger>
Wed 18 Aug 2010 02:59:32 AM UTC, comment #1:

Thanks for the report; however, this doesn't help yet. Can you go up one more level to `gray_render_line' and do some variable poking, particularly *worker?

Werner LEMBERG <wl>
Project Administrator
Tue 17 Aug 2010 04:04:43 PM UTC, original submission:

Font file: http://alt.swiecki.net/j/f/sigsegv32.ttf

Compiled with: -O0 -g

Platform: linux/amd64

$ gdb ./ftbench
(gdb) r -c 1 sigsegv32.ttf

Program received signal SIGSEGV, Segmentation fault.
0x000000000046e586 in gray_find_cell (worker=0x6a81d0) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:472
472 cell = *pcell;

(gdb) p pcell
$1 = (PCell *) 0x8006a8b78 <-- It's a vlaid heap address (0x6a8b78) and some index.

(gdb) p worker->ycells[worker->ey]
Cannot access memory at address 0x8006a8b78

(gdb) p worker->ycells
$5 = (PCell *) 0x6a8b50

(gdb) p/x worker->ey
$6 = 0x100000005 <-- way too big

(gdb) bt
#0 0x000000000046e586 in gray_find_cell (worker=0x6a81d0) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:472
#1 0x000000000046e698 in gray_record_cell (worker=0x6a81d0) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:503
#2 0x000000000046e757 in gray_set_cell (worker=0x6a81d0, ex=5, ey=5) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:546
#3 0x000000000046f06e in gray_render_line (worker=0x6a81d0, to_x=1380, to_y=1452) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:806
#4 0x000000000046f539 in gray_render_conic (worker=0x6a81d0, control=0x7fffffffddb0, to=0x7fffffffdd80) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:913
#5 0x0000000000470117 in gray_conic_to (control=0x7fffffffddb0, to=0x7fffffffdd80, worker=0x6a81d0) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1164
#6 0x000000000040bb34 in FT_Outline_Decompose (outline=0x6a88f8, func_interface=0x488360, user=0x6a81d0) at /usr/local/google/src/freetype2/src/base/ftoutln.c:190
#7 0x0000000000470766 in gray_convert_glyph_inner (worker=0x6a81d0) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1724
#8 0x0000000000470cb7 in gray_convert_glyph (worker=0x6a81d0) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1845
#9 0x00000000004711b9 in gray_raster_render (raster=0x6ad7a0, params=0x7fffffffe200) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1975
#10 0x000000000047187d in ft_smooth_render_generic (render=0x6ad6e0, slot=0x6aec30, mode=FT_RENDER_MODE_NORMAL, origin=0x0, required_mode=FT_RENDER_MODE_NORMAL) at /usr/local/google/src/freetype2/src/smooth/ftsmooth.c:292
#11 0x0000000000471afb in ft_smooth_render (render=0x6ad6e0, slot=0x6aec30, mode=FT_RENDER_MODE_NORMAL, origin=0x0) at /usr/local/google/src/freetype2/src/smooth/ftsmooth.c:378
#12 0x000000000040a996 in FT_Render_Glyph_Internal (library=0x6a8040, slot=0x6aec30, render_mode=FT_RENDER_MODE_NORMAL) at /usr/local/google/src/freetype2/src/base/ftobjs.c:3914
#13 0x000000000040aa6b in FT_Render_Glyph (slot=0x6aec30, render_mode=FT_RENDER_MODE_NORMAL) at /usr/local/google/src/freetype2/src/base/ftobjs.c:3954
#14 0x0000000000401964 in test_render (timer=0x7fffffffe480, face=0x6ada70, user_data=0x0) at /usr/local/google/src/freetype2-demos/src/ftbench.c:274
#15 0x00000000004016fe in benchmark (face=0x6ada70, test=0x7fffffffe4f0, max_iter=1, max_time=2) at /usr/local/google/src/freetype2-demos/src/ftbench.c:191
#16 0x00000000004028c8 in main (argc=1, argv=0x7fffffffe660) at /usr/local/google/src/freetype2-demos/src/ftbench.c:825

Also, two UPs in the gray_set_cell

(gdb) up
#1 0x000000000046e698 in gray_record_cell (worker=0x6a81d0) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:503
503 PCell cell = gray_find_cell( RAS_VAR );
(gdb) up
#2 0x000000000046e757 in gray_set_cell (worker=0x6a81d0, ex=5, ey=5) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:546
546 gray_record_cell( RAS_VAR );

(gdb) p/x worker->min_ey
$9 = 0x0
(gdb) p/x worker->max_ey
$10 = 0x6
(gdb) p/x worker->ey
$11 = 0x100000005
(gdb) p ey
$12 = 5
(gdb) p ex
$13 = 5

Robert Swiecki <jagger>

 

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

Attach File(s):
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by mpsuzuki (Posted a comment)
  • -unavailable- added by wl (Posted a comment)
  • -unavailable- added by jagger (Submitted the item)
  •  

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

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 12 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 01 Sep 2010 12:21:17 AM UTCmpsuzukiStatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Mon 30 Aug 2010 04:44:17 PM UTCmpsuzukiAttached File-=>Added fix-savannah-30798-rev2.diff, #21355
      StatusIn Progress=>Ready For Test
      Planned ReleaseNone=>2.4.3
    Mon 30 Aug 2010 01:18:30 PM UTCmpsuzukiStatusConfirmed=>In Progress
    Mon 30 Aug 2010 01:18:19 PM UTCmpsuzukiAttached File-=>Added fix-savannah-30798_p1-0.diff, #21352
    Mon 30 Aug 2010 09:15:18 AM UTCmpsuzukiAttached File-=>Added bug30793-dont-preserve-fpgm+prep_20100830a.diff, #21350
    Sat 28 Aug 2010 09:51:00 PM UTCmpsuzukiStatusNeed Info=>Confirmed
      Assigned towl=>mpsuzuki
    Wed 18 Aug 2010 02:59:32 AM UTCwlStatusNone=>Need Info
      Assigned toNone=>wl

    Back to the top


    Powered by Savane 3.1-cleanup1