bugThe FreeType Project - Bugs: bug #30263, SIGSEGV under certain conditions...

 
 

bug #30263: SIGSEGV under certain conditions in smooth/ftgrays.c:486

Submitted by:  Robert Swiecki <jagger>
Submitted on:  Fri 25 Jun 2010 02:11:12 PM UTC  
 
Severity: 3 - NormalItem Group: Crash
Status: FixedPrivacy: Public
Assigned to: Werner LEMBERG <wl>Open/Closed: Closed
Planned Release: 2.3.13

Add a New Comment (Rich MarkupRich 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)

Fri 02 Jul 2010 12:18:22 AM UTC, comment #19:

Yeah.. it doesn't produce any errors now.

Btw, I don't any more testcases crashing libfreetype now. I'll have the fuzzer working over-night, but I don't expect anything new.

So, thanks for fixing all those bugs, and happy development :).

Robert Swiecki <jagger>
Thu 01 Jul 2010 11:36:13 PM UTC, comment #18:

Please run the current git against sigsegv25.ttf again; hopefully, all valgrind errors are gone now – note that I get similar but different errors which probably have the same cause.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Wed 30 Jun 2010 02:47:19 PM UTC, comment #17:

Thanks for testing; I'll fix it in the repository. Regarding the other valgrind issue, I'm actually able to reproduce it, however, I wasn't able to reduce it to something I can debug: If I just run a part of the tests (for example, using the `-b c' command line option to test rendering only), the error doesn't occur. Strange. And the place where it happens is unfortunately very unspecific (namely the beginning of the interpreter loop). Of course, neither ftview nor any other demo program exhibits the valgrind error...

It will take some time to fix this since I have to insert a bunch of additional debugging messages into ftbench.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Wed 30 Jun 2010 02:29:06 PM UTC, comment #16:

Yeah... it passes right now w/o any crashes. There's another valgrind warning printed, but it seems it's in another part of the code

==6088== Memcheck, a memory error detector
==6088== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==6088== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info
==6088== Command: ./new.ftbench -c 1 sigsegv25.ttf
==6088==
Load : 1779.697 us/op
Load_Advances (Normal) : 0.198 us/op
Load_Advances (Fast) : 1.253 us/op
Render : ==6088== Invalid read of size 1
==6088== at 0x8061A2A: TT_RunIns /usr/local/google/src/freetype2/src/truetype/ttinterp.c:7143
==6088== by 0x805BD50: TT_Run_Context /usr/local/google/src/freetype2/src/truetype/ttinterp.c:742
==6088== by 0x8057F56: TT_Hint_Glyph /usr/local/google/src/freetype2/src/truetype/ttgload.c:816
==6088== by 0x8058A3E: TT_Process_Composite_Glyph /usr/local/google/src/freetype2/src/truetype/ttgload.c:1201
==6088== by 0x8059541: load_truetype_glyph /usr/local/google/src/freetype2/src/truetype/ttgload.c:1604
==6088== by 0x8059F05: TT_Load_Glyph /usr/local/google/src/freetype2/src/truetype/ttgload.c:2074
==6088== by 0x8056277: Load_Glyph /usr/local/google/src/freetype2/src/truetype/ttdriver.c:334
==6088== by 0x804C922: FT_Load_Glyph /usr/local/google/src/freetype2/src/base/ftobjs.c:677
==6088== by 0x8049151: test_render /usr/local/google/src/freetype2-demos/src/ftbench.c:265
==6088== by 0x8048FAA: benchmark /usr/local/google/src/freetype2-demos/src/ftbench.c:188
==6088== by 0x8049F0A: main /usr/local/google/src/freetype2-demos/src/ftbench.c:812
==6088== Address 0x6e5a8a2 is 5,634 bytes inside a block of size 15,759 free'd
==6088== at 0x47DD8E2: free /tmp/vg/coregrind/m_replacemalloc/vg_replace_malloc.c:394
==6088== by 0x80B3ECD: ft_free /usr/local/google/src/freetype2/builds/unix/ftsystem.c:158
==6088== by 0x80550C1: ft_mem_free /usr/local/google/src/freetype2/src/base/ftutil.c:171
==6088== by 0x804C020: ft_glyphslot_free_bitmap /usr/local/google/src/freetype2/src/base/ftobjs.c:265
==6088== by 0x804C107: ft_glyphslot_clear /usr/local/google/src/freetype2/src/base/ftobjs.c:311
==6088== by 0x804C6FB: FT_Load_Glyph /usr/local/google/src/freetype2/src/base/ftobjs.c:573
==6088== by 0x8049151: test_render /usr/local/google/src/freetype2-demos/src/ftbench.c:265
==6088== by 0x8048FAA: benchmark /usr/local/google/src/freetype2-demos/src/ftbench.c:188
==6088== by 0x8049F0A: main /usr/local/google/src/freetype2-demos/src/ftbench.c:812
==6088==
20927.484 us/op
Get_Glyph : ==6088== Invalid read of size 1
==6088== at 0x805DD73: Ins_PUSHB /usr/local/google/src/freetype2/src/truetype/ttinterp.c:4686
==6088== by 0x8062EAB: TT_RunIns /usr/local/google/src/freetype2/src/truetype/ttinterp.c:7730
==6088== by 0x805BD50: TT_Run_Context /usr/local/google/src/freetype2/src/truetype/ttinterp.c:742
==6088== by 0x8057F56: TT_Hint_Glyph /usr/local/google/src/freetype2/src/truetype/ttgload.c:816
==6088== by 0x8058A3E: TT_Process_Composite_Glyph /usr/local/google/src/freetype2/src/truetype/ttgload.c:1201
==6088== by 0x8059541: load_truetype_glyph /usr/local/google/src/freetype2/src/truetype/ttgload.c:1604
==6088== by 0x8059F05: TT_Load_Glyph /usr/local/google/src/freetype2/src/truetype/ttgload.c:2074
==6088== by 0x8056277: Load_Glyph /usr/local/google/src/freetype2/src/truetype/ttdriver.c:334
==6088== by 0x804C922: FT_Load_Glyph /usr/local/google/src/freetype2/src/base/ftobjs.c:677
==6088== by 0x804925F: test_get_glyph /usr/local/google/src/freetype2-demos/src/ftbench.c:315
==6088== by 0x8048FAA: benchmark /usr/local/google/src/freetype2-demos/src/ftbench.c:188
==6088== by 0x8049F43: main /usr/local/google/src/freetype2-demos/src/ftbench.c:817
==6088== Address 0x6e5a8bd is 709 bytes inside a block of size 2,512 free'd
==6088== at 0x47DD8E2: free /tmp/vg/coregrind/m_replacemalloc/vg_replace_malloc.c:394
==6088== by 0x80B3ECD: ft_free /usr/local/google/src/freetype2/builds/unix/ftsystem.c:158
==6088== by 0x80550C1: ft_mem_free /usr/local/google/src/freetype2/src/base/ftutil.c:171
==6088== by 0x8051B5B: FT_Outline_Done_Internal /usr/local/google/src/freetype2/src/base/ftoutln.c:429
==6088== by 0x8051C11: FT_Outline_Done /usr/local/google/src/freetype2/src/base/ftoutln.c:453
==6088== by 0x8055773: ft_outline_glyph_done /usr/local/google/src/freetype2/src/base/ftglyph.c:192
==6088== by 0x8055EF5: FT_Done_Glyph /usr/local/google/src/freetype2/src/base/ftglyph.c:620
==6088== by 0x8049291: test_get_glyph /usr/local/google/src/freetype2-demos/src/ftbench.c:321
==6088== by 0x8048FAA: benchmark /usr/local/google/src/freetype2-demos/src/ftbench.c:188
==6088== by 0x8049F43: main /usr/local/google/src/freetype2-demos/src/ftbench.c:817
==6088==
51.716 us/op
Get_CBox : 27.430 us/op
Get_Char_Index : inf us/op
Iterate CMap : 1009.941 us/op
New_Face : 27102.947 us/op
Embolden : ==6088== Invalid read of size 1
==6088== at 0x805D3D2: SkipCode /usr/local/google/src/freetype2/src/truetype/ttinterp.c:4150
==6088== by 0x805D680: Ins_FDEF /usr/local/google/src/freetype2/src/truetype/ttinterp.c:4314
==6088== by 0x8062448: TT_RunIns /usr/local/google/src/freetype2/src/truetype/ttinterp.c:7381
==6088== by 0x805BD50: TT_Run_Context /usr/local/google/src/freetype2/src/truetype/ttinterp.c:742
==6088== by 0x8057F56: TT_Hint_Glyph /usr/local/google/src/freetype2/src/truetype/ttgload.c:816
==6088== by 0x8058A3E: TT_Process_Composite_Glyph /usr/local/google/src/freetype2/src/truetype/ttgload.c:1201
==6088== by 0x8059541: load_truetype_glyph /usr/local/google/src/freetype2/src/truetype/ttgload.c:1604
==6088== by 0x8059F05: TT_Load_Glyph /usr/local/google/src/freetype2/src/truetype/ttgload.c:2074
==6088== by 0x8056277: Load_Glyph /usr/local/google/src/freetype2/src/truetype/ttdriver.c:334
==6088== by 0x804C922: FT_Load_Glyph /usr/local/google/src/freetype2/src/base/ftobjs.c:677
==6088== by 0x80491E6: test_embolden /usr/local/google/src/freetype2-demos/src/ftbench.c:289
==6088== by 0x8048FAA: benchmark /usr/local/google/src/freetype2-demos/src/ftbench.c:188
==6088== Address 0x6e5a8a5 is 2,029 bytes inside a block of size 3,888 free'd
==6088== at 0x47DD8E2: free /tmp/vg/coregrind/m_replacemalloc/vg_replace_malloc.c:394
==6088== by 0x80B3ECD: ft_free /usr/local/google/src/freetype2/builds/unix/ftsystem.c:158
==6088== by 0x80550C1: ft_mem_free /usr/local/google/src/freetype2/src/base/ftutil.c:171
==6088== by 0x8051B5B: FT_Outline_Done_Internal /usr/local/google/src/freetype2/src/base/ftoutln.c:429
==6088== by 0x8051C11: FT_Outline_Done /usr/local/google/src/freetype2/src/base/ftoutln.c:453
==6088== by 0x8055773: ft_outline_glyph_done /usr/local/google/src/freetype2/src/base/ftglyph.c:192
==6088== by 0x8055EF5: FT_Done_Glyph /usr/local/google/src/freetype2/src/base/ftglyph.c:620
==6088== by 0x804936D: test_get_cbox /usr/local/google/src/freetype2-demos/src/ftbench.c:355
==6088== by 0x8048FAA: benchmark /usr/local/google/src/freetype2-demos/src/ftbench.c:188
==6088== by 0x8049F7C: main /usr/local/google/src/freetype2-demos/src/ftbench.c:822
==6088==
2.481 us/op
==6088==
==6088== HEAP SUMMARY:
==6088== in use at exit: 0 bytes in 0 blocks
==6088== total heap usage: 133,545 allocs, 133,545 frees, 4,695,769,572 bytes allocated
==6088==
==6088== All heap blocks were freed -- no leaks are possible
==6088==
==6088== For counts of detected and suppressed errors, rerun with: -v
==6088== ERROR SUMMARY: 3370 errors from 3 contexts (suppressed: 13 from 0)

Robert Swiecki <jagger>
Wed 30 Jun 2010 02:15:19 PM UTC, comment #15:

Even a 0x7FFF x 0x7FFF bitmap is quite large :)

Your analysis looks convincing (and thanks for taking time to look into that issue). Can you change the two values in the source code and test whether it fixes the problem?

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Wed 30 Jun 2010 02:06:47 PM UTC, comment #14:

And that values come from:

smooth/ftsmooth.c: ft_smooth_render_generic()

There's an preprocessor #if (line 199)

#if FT_UINT_MAX > 0xFFFFU

/* Required check is ( pitch * height < FT_ULONG_MAX ), */
/* but we care realistic cases only. Always pitch <= width. */
if ( width > 0xFFFFU || height > 0xFFFFU )
{
FT_ERROR(( "ft_smooth_render_generic: glyph too large: %d x %d\n",
width, height ));
return Smooth_Err_Raster_Overflow;
}

#endif

bitmap->pixel_mode = FT_PIXEL_MODE_GRAY;
bitmap->num_grays = 256;
bitmap->width = width;
bitmap->rows = height;
bitmap->pitch = pitch;

but, IMO it should check for width / height being greater than 0x7FFF, and not 0xFFFF - cause of this multiplication in src/smooth/ftgrays.c .

p += ( map->rows - 1 ) * map->pitch;

Robert Swiecki <jagger>
Wed 30 Jun 2010 01:44:34 PM UTC, comment #13:

Before I do that, maybe this will help. It seems that the problem might be caused by an integer overflow.

From src/smooth/ftgrays.c : 1187

/* first of all, compute the scanline offset */
p = (unsigned char)map->buffer - y map->pitch;
if ( map->pitch >= 0 )
p += ( map->rows - 1 ) * map->pitch;

Values:
(gdb) up
#1 0x0000000000470fe2 in gray_render_span (y=0, count=32, spans=0x6a8958, worker=0x6a81c0) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1203
1203 FT_MEM_SET( p + spans->x, (unsigned char)coverage, spans->len );

(gdb) p (map->buffer - y * map->pitch)
$25 = (unsigned char *) 0x7fff65518010 ""

(gdb) p ( map->rows - 1 ) * map->pitch <-- integer overflow, it is caused by multiplying two unsigned values
$26 = -1848490702

(gdb) p map->rows
$29 = 65263

(gdb) p map->pitch
$30 = 37487

(gdb) p (map->buffer - y * map->pitch) + (( map->rows - 1 ) * map->pitch)
$27 = (unsigned char *) 0x7ffef723c542 <Address 0x7ffef723c542 out of bounds>

When using unsigned multiplication the result seems ok

(gdb) p (map->buffer - y * map->pitch) + (unsigned)(( map->rows - 1 ) * map->pitch)
$32 = (unsigned char *) 0x7ffff723c542 ""

Robert Swiecki <jagger>
Wed 30 Jun 2010 11:20:31 AM UTC, comment #12:

Thanks, the binary reproduced SEGV crashing on my GNU/Linux
amd64 machine (2GB RAM + 3GB swap). Following is my valgrind
log. jagger, could you make a tarball including everything of your
FreeType2 building for further investigation? If possible, I want you
to pack "freetype2" directory after building with CFLAGS
"-g -O0 -save-temps" to keep cpp outputs.

==21826== Memcheck, a memory error detector
==21826== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==21826== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info
==21826== Command: ./ftbench -c 1 sigsegv25.ttf
==21826==
==21826== Conditional jump or move depends on uninitialised value(s)
==21826== at 0x4016236: index (strchr.S:56)
==21826== by 0x4007164: expand_dynamic_string_token (dl-load.c:324)
==21826== by 0x4007567: _dl_map_object (dl-load.c:2173)
==21826== by 0x400186A: map_doit (rtld.c:634)
==21826== by 0x400D5C5: _dl_catch_error (dl-error.c:178)
==21826== by 0x400176E: do_preload (rtld.c:818)
==21826== by 0x40043F1: dl_main (rtld.c:1678)
==21826== by 0x4014776: _dl_sysdep_start (dl-sysdep.c:243)
==21826== by 0x4001422: _dl_start (rtld.c:338)
==21826== by 0x4000AF7: ??? (in /lib/ld-2.11.2.so)
==21826== by 0x3: ???
==21826== by 0x7FF0003BA: ???
==21826==
==21826== Conditional jump or move depends on uninitialised value(s)
==21826== at 0x401623B: index (strchr.S:59)
==21826== by 0x4007164: expand_dynamic_string_token (dl-load.c:324)
==21826== by 0x4007567: _dl_map_object (dl-load.c:2173)
==21826== by 0x400186A: map_doit (rtld.c:634)
==21826== by 0x400D5C5: _dl_catch_error (dl-error.c:178)
==21826== by 0x400176E: do_preload (rtld.c:818)
==21826== by 0x40043F1: dl_main (rtld.c:1678)
==21826== by 0x4014776: _dl_sysdep_start (dl-sysdep.c:243)
==21826== by 0x4001422: _dl_start (rtld.c:338)
==21826== by 0x4000AF7: ??? (in /lib/ld-2.11.2.so)
==21826== by 0x3: ???
==21826== by 0x7FF0003BA: ???
==21826==
==21826== Conditional jump or move depends on uninitialised value(s)
==21826== at 0x400AC3E: _dl_relocate_object (do-rel.h:65)
==21826== by 0x400383A: dl_main (rtld.c:2297)
==21826== by 0x4014776: _dl_sysdep_start (dl-sysdep.c:243)
==21826== by 0x4001422: _dl_start (rtld.c:338)
==21826== by 0x4000AF7: ??? (in /lib/ld-2.11.2.so)
==21826== by 0x3: ???
==21826== by 0x7FF0003BA: ???
==21826== by 0x7FF0003C4: ???
==21826== by 0x7FF0003C7: ???
==21826== by 0x7FF0003C9: ???
==21826==
==21826== Conditional jump or move depends on uninitialised value(s)
==21826== at 0x400AC47: _dl_relocate_object (do-rel.h:68)
==21826== by 0x400383A: dl_main (rtld.c:2297)
==21826== by 0x4014776: _dl_sysdep_start (dl-sysdep.c:243)
==21826== by 0x4001422: _dl_start (rtld.c:338)
==21826== by 0x4000AF7: ??? (in /lib/ld-2.11.2.so)
==21826== by 0x3: ???
==21826== by 0x7FF0003BA: ???
==21826== by 0x7FF0003C4: ???
==21826== by 0x7FF0003C7: ???
==21826== by 0x7FF0003C9: ???
==21826==
Load : 13638.011 us/op
Load_Advances (Normal) : 0.866 us/op
Load_Advances (Fast) : 9.007 us/op
Render : ==21826== Warning: set address range perms: large range [0x3915b040, 0xcae887e1) (undefined)
==21826== Invalid write of size 1
==21826== at 0x4C260A8: memset (mc_replace_strmem.c:586)
==21826== by 0x470FE1: gray_render_span (ftgrays.c:1203)
==21826== by 0x47125C: gray_hline (ftgrays.c:1292)
==21826== by 0x471394: gray_sweep (ftgrays.c:1385)
==21826== by 0x471AA7: gray_convert_glyph (ftgrays.c:1845)
==21826== by 0x471F80: gray_raster_render (ftgrays.c:1971)
==21826== by 0x4725DC: ft_smooth_render_generic (ftsmooth.c:274)
==21826== by 0x47285A: ft_smooth_render (ftsmooth.c:360)
==21826== by 0x40B0BE: FT_Render_Glyph_Internal (ftobjs.c:3817)
==21826== by 0x40B193: FT_Render_Glyph (ftobjs.c:3857)
==21826== by 0x4020EE: test_render (ftbench.c:269)
==21826== by 0x401E97: benchmark (ftbench.c:188)
==21826== Address 0xffffffffcae85832 is not stack'd, malloc'd or (recently) free'd
==21826==
==21826==
==21826== Process terminating with default action of signal 11 (SIGSEGV)
==21826== Access not within mapped region at address 0xFFFFFFFFCAE85832
==21826== at 0x4C260A8: memset (mc_replace_strmem.c:586)
==21826== by 0x470FE1: gray_render_span (ftgrays.c:1203)
==21826== by 0x47125C: gray_hline (ftgrays.c:1292)
==21826== by 0x471394: gray_sweep (ftgrays.c:1385)
==21826== by 0x471AA7: gray_convert_glyph (ftgrays.c:1845)
==21826== by 0x471F80: gray_raster_render (ftgrays.c:1971)
==21826== by 0x4725DC: ft_smooth_render_generic (ftsmooth.c:274)
==21826== by 0x47285A: ft_smooth_render (ftsmooth.c:360)
==21826== by 0x40B0BE: FT_Render_Glyph_Internal (ftobjs.c:3817)
==21826== by 0x40B193: FT_Render_Glyph (ftobjs.c:3857)
==21826== by 0x4020EE: test_render (ftbench.c:269)
==21826== by 0x401E97: benchmark (ftbench.c:188)
==21826== If you believe this happened as a result of a stack
==21826== overflow in your program's main thread (unlikely but
==21826== possible), you can try to increase the size of the
==21826== main thread stack using the --main-stacksize= flag.
==21826== The main thread stack size used in this run was 8388608.
==21826==
==21826== HEAP SUMMARY:
==21826== in use at exit: 2,448,116,679 bytes in 85 blocks
==21826== total heap usage: 3,417 allocs, 3,332 frees, 2,459,191,128 bytes allocated
==21826==
==21826== LEAK SUMMARY:
==21826== definitely lost: 0 bytes in 0 blocks
==21826== indirectly lost: 0 bytes in 0 blocks
==21826== possibly lost: 0 bytes in 0 blocks
==21826== still reachable: 2,448,116,679 bytes in 85 blocks
==21826== suppressed: 0 bytes in 0 blocks
==21826== Rerun with --leak-check=full to see details of leaked memory
==21826==
==21826== For counts of detected and suppressed errors, rerun with: -v
==21826== Use --track-origins=yes to see where uninitialised values come from
==21826== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 0 from 0)

suzuki toshiya <mpsuzuki>
Project Administrator
Wed 30 Jun 2010 09:41:08 AM UTC, comment #11:

Yeah.. try this one

http://alt.swiecki.net/j/f/ftbench

It's libc/libz dependent only. If that will not work, I'll prepare a fully-static binary.

$ ldd ./ftbench '
libz.so.1 => /usr/lib/libz.so.1 (0x00002b8d29222000)
libc.so.6 => /lib/libc.so.6 (0x00002b8d29439000)
/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)

Robert Swiecki <jagger>
Wed 30 Jun 2010 01:19:09 AM UTC, comment #10:

I couldn't reproduce this issue on my amd64 GNU/Linux
machine. jagger, could you upload statically-built binary
of ftbench?

suzuki toshiya <mpsuzuki>
Project Administrator
Tue 29 Jun 2010 03:29:43 PM UTC, comment #9:

I'm sorry, I don't have 64bit machine with 8GB RAM,
I will try to reproduce the issue on amd64 machine
with smaller memory. Please wait.

Although my university has a super computer Hitachi
SR11000 (AIX running on) which a process can use
memory 48GB-100GB, this issue won't be reproduced
on it.

suzuki toshiya <mpsuzuki>
Project Administrator
Mon 28 Jun 2010 07:30:44 PM UTC, comment #8:

I fear I can't debug this with my limited amount of main memory built into my Laptop. If you look at the number of allocated bytes valgrind reports, this is far beyond what I can handle gracefully.

Toshiya-san, do you have a machine with more RAM?

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Mon 28 Jun 2010 03:23:44 PM UTC, comment #7:

Well, actually the valgrind is a little bit different in the 32bit case.

==13462== Memcheck, a memory error detector
==13462== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==13462== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info
==13462== Command: ./ftbench -c 1 ttf/sigsegv25.ttf
==13462==
Load : 2189.319 us/op
Load_Advances (Normal) : 0.218 us/op
Load_Advances (Fast) : 1.479 us/op
Render : ==13462== Warning: set address range perms: large range [0x3b41b040, 0xcd1487e1) (undefined)
==13462== Invalid write of size 1
==13462== at 0x4C2B488: memset /tmp/vg/memcheck/mc_replace_strmem.c:602
==13462== by 0x470FE1: gray_render_span /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1203
==13462== by 0x47125C: gray_hline /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1292
==13462== by 0x471394: gray_sweep /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1385
==13462== by 0x471AA7: gray_convert_glyph /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1845
==13462== by 0x471F80: gray_raster_render /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1971
==13462== by 0x4725DC: ft_smooth_render_generic /usr/local/google/src/freetype2/src/smooth/ftsmooth.c:274
==13462== by 0x47285A: ft_smooth_render /usr/local/google/src/freetype2/src/smooth/ftsmooth.c:360
==13462== by 0x40B0BE: FT_Render_Glyph_Internal /usr/local/google/src/freetype2/src/base/ftobjs.c:3817
==13462== by 0x40B193: FT_Render_Glyph /usr/local/google/src/freetype2/src/base/ftobjs.c:3857
==13462== by 0x4020EE: test_render /usr/local/google/src/freetype2-demos/src/ftbench.c:269
==13462== by 0x401E97: benchmark /usr/local/google/src/freetype2-demos/src/ftbench.c:188
==13462== Address 0xffffffffcd145832 is not stack'd, malloc'd or (recently) free'd
==13462==
==13462==
==13462== Process terminating with default action of signal 11 (SIGSEGV)
==13462== Access not within mapped region at address 0xFFFFFFFFCD145832
==13462== at 0x4C2B488: memset /tmp/vg/memcheck/mc_replace_strmem.c:602
==13462== by 0x470FE1: gray_render_span /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1203
==13462== by 0x47125C: gray_hline /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1292
==13462== by 0x471394: gray_sweep /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1385
==13462== by 0x471AA7: gray_convert_glyph /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1845
==13462== by 0x471F80: gray_raster_render /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1971
==13462== by 0x4725DC: ft_smooth_render_generic /usr/local/google/src/freetype2/src/smooth/ftsmooth.c:274
==13462== by 0x47285A: ft_smooth_render /usr/local/google/src/freetype2/src/smooth/ftsmooth.c:360
==13462== by 0x40B0BE: FT_Render_Glyph_Internal /usr/local/google/src/freetype2/src/base/ftobjs.c:3817
==13462== by 0x40B193: FT_Render_Glyph /usr/local/google/src/freetype2/src/base/ftobjs.c:3857
==13462== by 0x4020EE: test_render /usr/local/google/src/freetype2-demos/src/ftbench.c:269
==13462== by 0x401E97: benchmark /usr/local/google/src/freetype2-demos/src/ftbench.c:188
==13462== If you believe this happened as a result of a stack
==13462== overflow in your program's main thread (unlikely but
==13462== possible), you can try to increase the size of the
==13462== main thread stack using the --main-stacksize= flag.
==13462== The main thread stack size used in this run was 8388608.
==13462==
==13462== HEAP SUMMARY:
==13462== in use at exit: 2,448,116,679 bytes in 85 blocks
==13462== total heap usage: 3,417 allocs, 3,332 frees, 2,459,191,128 bytes allocated
==13462==
==13462== LEAK SUMMARY:
==13462== definitely lost: 0 bytes in 0 blocks
==13462== indirectly lost: 0 bytes in 0 blocks
==13462== possibly lost: 0 bytes in 0 blocks
==13462== still reachable: 2,448,116,679 bytes in 85 blocks
==13462== suppressed: 0 bytes in 0 blocks
==13462== Rerun with --leak-check=full to see details of leaked memory
==13462==
==13462== For counts of detected and suppressed errors, rerun with: -v
==13462== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 0)

Robert Swiecki <jagger>
Mon 28 Jun 2010 03:12:30 PM UTC, comment #6:

Hm.. I have 8GB so I'm noticing memory issues.. :)

I have 3 fonts which were segfaulting in gray_ - but now only

http://alt.swiecki.net/j/f/sigsegv23.otf

and

http://alt.swiecki.net/j/f/sigsegv25.ttf

cause this, so your fix might have helped a little. Btw, it doesn't crash 32bit compiled binary (it still produces the same valgrind warnings, though), so it looks like it's pure 64bit problem.

It still produces the same valgrind problems.

$ valgrind ./ftbench -c 1 ttf/sigsegv23.otf
VALGRIND_MEMORY_LIMIT_IN_MB=4095; VALGRIND_TIMEOUT=3600
==32258== Memcheck, a memory error detector
==32258== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==32258== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info
==32258== Command: ./ftbench -c 1 ttf/sigsegv23.otf
==32258==
Load : 1473.026 us/op
Load_Advances (Normal) : 2.890 us/op
Load_Advances (Fast) : 1.731 us/op
Render : ==32258== Warning: set address range perms: large range [0x3b41b040, 0xd7827840) (undefined)
==32258== Invalid write of size 1
==32258== at 0x471069: gray_render_span /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1216
==32258== by 0x47125C: gray_hline /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1292
==32258== by 0x4713FA: gray_sweep /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1392
==32258== by 0x471AA7: gray_convert_glyph /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1845
==32258== by 0x471F80: gray_raster_render /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1971
==32258== by 0x4725DC: ft_smooth_render_generic /usr/local/google/src/freetype2/src/smooth/ftsmooth.c:274
==32258== by 0x47285A: ft_smooth_render /usr/local/google/src/freetype2/src/smooth/ftsmooth.c:360
==32258== by 0x40B0BE: FT_Render_Glyph_Internal /usr/local/google/src/freetype2/src/base/ftobjs.c:3817
==32258== by 0x40B193: FT_Render_Glyph /usr/local/google/src/freetype2/src/base/ftobjs.c:3857
==32258== by 0x4020EE: test_render /usr/local/google/src/freetype2-demos/src/ftbench.c:269
==32258== by 0x401E97: benchmark /usr/local/google/src/freetype2-demos/src/ftbench.c:188
==32258== by 0x403165: main /usr/local/google/src/freetype2-demos/src/ftbench.c:812
==32258== Address 0xffffffffd781c83f is not stack'd, malloc'd or (recently) free'd
==32258==
==32258==
==32258== Process terminating with default action of signal 11 (SIGSEGV)
==32258== Access not within mapped region at address 0xFFFFFFFFD781C83F
==32258== at 0x471069: gray_render_span /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1216
==32258== by 0x47125C: gray_hline /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1292
==32258== by 0x4713FA: gray_sweep /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1392
==32258== by 0x471AA7: gray_convert_glyph /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1845
==32258== by 0x471F80: gray_raster_render /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1971
==32258== by 0x4725DC: ft_smooth_render_generic /usr/local/google/src/freetype2/src/smooth/ftsmooth.c:274
==32258== by 0x47285A: ft_smooth_render /usr/local/google/src/freetype2/src/smooth/ftsmooth.c:360
==32258== by 0x40B0BE: FT_Render_Glyph_Internal /usr/local/google/src/freetype2/src/base/ftobjs.c:3817
==32258== by 0x40B193: FT_Render_Glyph /usr/local/google/src/freetype2/src/base/ftobjs.c:3857
==32258== by 0x4020EE: test_render /usr/local/google/src/freetype2-demos/src/ftbench.c:269
==32258== by 0x401E97: benchmark /usr/local/google/src/freetype2-demos/src/ftbench.c:188
==32258== by 0x403165: main /usr/local/google/src/freetype2-demos/src/ftbench.c:812
==32258== If you believe this happened as a result of a stack
==32258== overflow in your program's main thread (unlikely but
==32258== possible), you can try to increase the size of the
==32258== main thread stack using the --main-stacksize= flag.
==32258== The main thread stack size used in this run was 8388608.
==32258==
==32258== HEAP SUMMARY:
==32258== in use at exit: 2,621,808,052 bytes in 96 blocks
==32258== total heap usage: 1,036 allocs, 940 frees, 2,622,300,292 bytes allocated
==32258==
==32258== LEAK SUMMARY:
==32258== definitely lost: 0 bytes in 0 blocks
==32258== indirectly lost: 0 bytes in 0 blocks
==32258== possibly lost: 896 bytes in 20 blocks
==32258== still reachable: 2,621,807,156 bytes in 76 blocks
==32258== suppressed: 0 bytes in 0 blocks
==32258== Rerun with --leak-check=full to see details of leaked memory
==32258==
==32258== For counts of detected and suppressed errors, rerun with: -v
==32258== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 0)

Robert Swiecki <jagger>
Sun 27 Jun 2010 09:45:23 PM UTC, comment #5:

I've found and fixed some bugs in the cff code, however, I still don't get a crash in the smooth module. Maybe a 32/64bit issue?

Note that I'm using

echo 2 > /proc/sys/vm/overcommit_memory

on my GNU/Linux box, otherwise Linux lets ftbench allocate too much memory for rendering the (buggy) glyphs in sigsegv23.otf, making my system unusable.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Sun 27 Jun 2010 01:17:39 AM UTC, comment #4:

> What about this one: http://alt.swiecki.net/j/f/sigsegv22.pfr


MOn dieu :).. http://alt.swiecki.net/j/f/sigsegv23.otf

Robert Swiecki <jagger>
Sun 27 Jun 2010 12:59:36 AM UTC, comment #3:

What about this one: http://alt.swiecki.net/j/f/sigsegv22.pfr

It also causes SEGV somewhere in gray_ functions, might be related

(gdb) r -c 1 sigsegv23.otf
Starting program: /usr/local/google/fuzz/ttf/ftbench -c 1 sigsegv23.otf

Program received signal SIGSEGV, Segmentation fault.
0x0000000000471d6d in gray_render_span (y=0, count=1, spans=0x6a9968, worker=0x6a91d0) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1216
1216 case 2: *q++ = (unsigned char)coverage;

(gdb) p *q
Cannot access memory at address 0x7ffef783680f

(gdb) bt
#0 0x0000000000471d6d in gray_render_span (y=0, count=1, spans=0x6a9968, worker=0x6a91d0) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1216
#1 0x0000000000471f61 in gray_hline (worker=0x6a91d0, x=6142, y=1, area=-16, acount=1) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1292
#2 0x00000000004720ff in gray_sweep (worker=0x6a91d0, target=0x6a9920) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1392
#3 0x00000000004727ae in gray_convert_glyph (worker=0x6a91d0) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1845
#4 0x0000000000472c89 in gray_raster_render (raster=0x6ae800, params=0x7fffffffe5c0) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1971
#5 0x00000000004732e5 in ft_smooth_render_generic (render=0x6ae730, slot=0x6b1860, mode=FT_RENDER_MODE_NORMAL, origin=0x0, required_mode=FT_RENDER_MODE_NORMAL) at /usr/local/google/src/freetype2/src/smooth/ftsmooth.c:274
#6 0x0000000000473563 in ft_smooth_render (render=0x6ae730, slot=0x6b1860, mode=FT_RENDER_MODE_NORMAL, origin=0x0) at /usr/local/google/src/freetype2/src/smooth/ftsmooth.c:360
#7 0x000000000040b813 in FT_Render_Glyph_Internal (library=0x6a9040, slot=0x6b1860, render_mode=FT_RENDER_MODE_NORMAL) at /usr/local/google/src/freetype2/src/base/ftobjs.c:3817
#8 0x000000000040b8e8 in FT_Render_Glyph (slot=0x6b1860, render_mode=FT_RENDER_MODE_NORMAL) at /usr/local/google/src/freetype2/src/base/ftobjs.c:3857
#9 0x00000000004027ff in test_render (timer=0x7fffffffe840, face=0x6aeb40, user_data=0x0) at /usr/local/google/src/freetype2-demos/src/ftbench.c:269
#10 0x00000000004025a8 in benchmark (face=0x6aeb40, test=0x7fffffffe8b0, max_iter=1, max_time=2) at /usr/local/google/src/freetype2-demos/src/ftbench.c:188
#11 0x0000000000403876 in main (argc=1, argv=0x7fffffffea30) at /usr/local/google/src/freetype2-demos/src/ftbench.c:812

$ valgrind ./ftbench -c 1 sigsegv23.otf
VALGRIND_MEMORY_LIMIT_IN_MB=4095; VALGRIND_TIMEOUT=3600
==2932== Memcheck, a memory error detector
==2932== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==2932== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info
==2932== Command: ./ftbench -c 1 sigsegv23.otf
==2932==
Load : 1387.123 us/op
Load_Advances (Normal) : 2.929 us/op
Load_Advances (Fast) : 1.459 us/op
Render :

==2932== Warning: set address range perms: large range [0x3b41b040, 0xd7827840) (undefined)

==2932== Invalid write of size 1
==2932== at 0x471D6D: gray_render_span /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1216
==2932== by 0x471F60: gray_hline /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1292
==2932== by 0x4720FE: gray_sweep /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1392
==2932== by 0x4727AD: gray_convert_glyph /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1845
==2932== by 0x472C88: gray_raster_render /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1971
==2932== by 0x4732E4: ft_smooth_render_generic /usr/local/google/src/freetype2/src/smooth/ftsmooth.c:274
==2932== by 0x473562: ft_smooth_render /usr/local/google/src/freetype2/src/smooth/ftsmooth.c:360
==2932== by 0x40B812: FT_Render_Glyph_Internal /usr/local/google/src/freetype2/src/base/ftobjs.c:3817
==2932== by 0x40B8E7: FT_Render_Glyph /usr/local/google/src/freetype2/src/base/ftobjs.c:3857
==2932== by 0x4027FE: test_render /usr/local/google/src/freetype2-demos/src/ftbench.c:269
==2932== by 0x4025A7: benchmark /usr/local/google/src/freetype2-demos/src/ftbench.c:188
==2932== by 0x403875: main /usr/local/google/src/freetype2-demos/src/ftbench.c:812
==2932== Address 0xffffffffd781c83f is not stack'd, malloc'd or (recently) free'd
==2932==
==2932==
==2932== Process terminating with default action of signal 11 (SIGSEGV)
==2932== Access not within mapped region at address 0xFFFFFFFFD781C83F
==2932== at 0x471D6D: gray_render_span /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1216
==2932== by 0x471F60: gray_hline /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1292
==2932== by 0x4720FE: gray_sweep /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1392
==2932== by 0x4727AD: gray_convert_glyph /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1845
==2932== by 0x472C88: gray_raster_render /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1971
==2932== by 0x4732E4: ft_smooth_render_generic /usr/local/google/src/freetype2/src/smooth/ftsmooth.c:274
==2932== by 0x473562: ft_smooth_render /usr/local/google/src/freetype2/src/smooth/ftsmooth.c:360
==2932== by 0x40B812: FT_Render_Glyph_Internal /usr/local/google/src/freetype2/src/base/ftobjs.c:3817
==2932== by 0x40B8E7: FT_Render_Glyph /usr/local/google/src/freetype2/src/base/ftobjs.c:3857
==2932== by 0x4027FE: test_render /usr/local/google/src/freetype2-demos/src/ftbench.c:269
==2932== by 0x4025A7: benchmark /usr/local/google/src/freetype2-demos/src/ftbench.c:188
==2932== by 0x403875: main /usr/local/google/src/freetype2-demos/src/ftbench.c:812
==2932== If you believe this happened as a result of a stack
==2932== overflow in your program's main thread (unlikely but
==2932== possible), you can try to increase the size of the
==2932== main thread stack using the --main-stacksize= flag.
==2932== The main thread stack size used in this run was 8388608.
==2932==
==2932== HEAP SUMMARY:
==2932== in use at exit: 2,621,808,052 bytes in 96 blocks
==2932== total heap usage: 1,036 allocs, 940 frees, 2,622,300,292 bytes allocated

(file #20828)

Robert Swiecki <jagger>
Sun 27 Jun 2010 12:43:54 AM UTC, comment #2:

I think I've fixed the problem with line 404 in pfrgload.c (now in git). However, I can't reproduce the problem in ftgrays.c.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Fri 25 Jun 2010 02:15:01 PM UTC, comment #1:

And valgrind output, not sure if it's really related to the problem described below:

$ valgrind ./ftbench -c 1 sigsegv22.pfr
VALGRIND_MEMORY_LIMIT_IN_MB=4095; VALGRIND_TIMEOUT=3600
==13015== Memcheck, a memory error detector
==13015== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==13015== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info
==13015== Command: ./ftbench -c 1 sigsegv22.pfr
==13015==
Load : ==13015== Invalid read of size 8
==13015== at 0x43DD33: pfr_glyph_load_simple /usr/local/google/src/freetype2/src/pfr/pfrgload.c:404
==13015== by 0x43E957: pfr_glyph_load_rec /usr/local/google/src/freetype2/src/pfr/pfrgload.c:808
==13015== by 0x43E9D3: pfr_glyph_load /usr/local/google/src/freetype2/src/pfr/pfrgload.c:834
==13015== by 0x43F4F8: pfr_slot_load /usr/local/google/src/freetype2/src/pfr/pfrobjs.c:345
==13015== by 0x406ADD: FT_Load_Glyph /usr/local/google/src/freetype2/src/base/ftobjs.c:677
==13015== by 0x46445D: af_loader_load_g /usr/local/google/src/freetype2/src/autofit/afloader.c:99
==13015== by 0x46561D: af_loader_load_glyph /usr/local/google/src/freetype2/src/autofit/afloader.c:531
==13015== by 0x4656B4: af_autofitter_load_glyph /usr/local/google/src/freetype2/src/autofit/afmodule.c:65
==13015== by 0x406A9E: FT_Load_Glyph /usr/local/google/src/freetype2/src/base/ftobjs.c:668
==13015== by 0x402672: test_load /usr/local/google/src/freetype2-demos/src/ftbench.c:218
==13015== by 0x4025A7: benchmark /usr/local/google/src/freetype2-demos/src/ftbench.c:188
==13015== by 0x40374D: main /usr/local/google/src/freetype2-demos/src/ftbench.c:781
==13015== Address 0x53dbfe0 is 0 bytes after a block of size 128 alloc'd
==13015== at 0x4C28DC6: realloc /tmp/vg/coregrind/m_replacemalloc/vg_replace_malloc.c:566
==13015== by 0x480C44: ft_realloc /usr/local/google/src/freetype2/builds/unix/ftsystem.c:135
==13015== by 0x4111BD: ft_mem_qrealloc /usr/local/google/src/freetype2/src/base/ftutil.c:154
==13015== by 0x411061: ft_mem_realloc /usr/local/google/src/freetype2/src/base/ftutil.c:101
==13015== by 0x43DA2F: pfr_glyph_load_simple /usr/local/google/src/freetype2/src/pfr/pfrgload.c:297
==13015== by 0x43E957: pfr_glyph_load_rec /usr/local/google/src/freetype2/src/pfr/pfrgload.c:808
==13015== by 0x43E9D3: pfr_glyph_load /usr/local/google/src/freetype2/src/pfr/pfrgload.c:834
==13015== by 0x43F4F8: pfr_slot_load /usr/local/google/src/freetype2/src/pfr/pfrobjs.c:345
==13015== by 0x406ADD: FT_Load_Glyph /usr/local/google/src/freetype2/src/base/ftobjs.c:677
==13015== by 0x46445D: af_loader_load_g /usr/local/google/src/freetype2/src/autofit/afloader.c:99
==13015== by 0x46561D: af_loader_load_glyph /usr/local/google/src/freetype2/src/autofit/afloader.c:531
==13015== by 0x4656B4: af_autofitter_load_glyph /usr/local/google/src/freetype2/src/autofit/afmodule.c:65
==13015==
1487.141 us/op
Load_Advances (Normal) : 15.273 us/op
Load_Advances (Fast) : 11.859 us/op
Render : 723.186 us/op
Get_Glyph : 134.833 us/op
Get_CBox : 26.735 us/op
Get_Char_Index : inf us/op
Iterate CMap : 846.863 us/op
New_Face : 16853.094 us/op
Embolden : 3.770 us/op
==13015==
==13015== HEAP SUMMARY:
==13015== in use at exit: 0 bytes in 0 blocks
==13015== total heap usage: 1,959 allocs, 1,959 frees, 697,559 bytes allocated
==13015==
==13015== All heap blocks were freed -- no leaks are possible
==13015==
==13015== For counts of detected and suppressed errors, rerun with: -v
==13015== ERROR SUMMARY: 5 errors from 1 contexts (suppressed: 4 from 0)

Robert Swiecki <jagger>
Fri 25 Jun 2010 02:11:12 PM UTC, original submission:

This might not be easy to reproduce, .. anyway.

Linux amd64, gcc version 4.4.3, compiled with "-O0 -g"

Font: http://alt.swiecki.net/j/f/sigsegv22.pfr

I tworks only when I set MALLOC_CHECK_=3 = not sure if this is really related to any additional checks in glibc, or maybe it changes how the stack looks like...

$ gdb ./ftbench
(gdb) r -c 1 sigsegv22.pfr
Program received signal SIGSEGV, Segmentation fault.
0x0000000000470002 in gray_find_cell (worker=0x6a91d0) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:468
468 cell = *pcell;

(gdb) p *pcell
Cannot access memory at address 0x460000006a9cd0 <--- this looks like off-by-one problem. The 0x6a9cd0 is located on heap.. and the 0x46 at the MSBits is letter 'F'. Anyway, the main offender seems to be this loop

pcell = &ras.ycells[ras.ey];
for (;;)
{
cell = *pcell;
if ( cell == NULL || cell->x > x )
break;

if ( cell->x == x )
goto Exit;

pcell = &cell->next;
}

The gray_find_cell() function is invoked many times, and at some point the ras.ey (a.k.a. worker->ey) holds

(gdb) p/x worker->ey
$2 = 0x8c00000000030

which looks bogus, especially in the context of pcell = &ras.ycells[ras.ey];

stacktrace

(gdb) bt
#0 0x0000000000470002 in gray_find_cell (worker=0x6a91d0) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:468
#1 0x0000000000470114 in gray_record_cell (worker=0x6a91d0) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:499
#2 0x00000000004701d3 in gray_set_cell (worker=0x6a91d0, ex=5, ey=2462906046218287) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:542
#3 0x0000000000470be2 in gray_render_line (worker=0x6a91d0, to_x=1352, to_y=10943) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:833
#4 0x0000000000471a71 in gray_render_cubic (worker=0x6a91d0, control1=0x7fffffffdd70, control2=0x7fffffffdd60, to=0x7fffffffdd50) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1112
#5 0x0000000000471bce in gray_cubic_to (control1=0x7fffffffdd70, control2=0x7fffffffdd60, to=0x7fffffffdd50, worker=0x6a91d0) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1171
#6 0x000000000040caf2 in FT_Outline_Decompose (outline=0x6a98f8, func_interface=0x6a6760, user=0x6a91d0) at /usr/local/google/src/freetype2/src/base/ftoutln.c:252
#7 0x0000000000472200 in gray_convert_glyph_inner (worker=0x6a91d0) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1720
#8 0x0000000000472751 in gray_convert_glyph (worker=0x6a91d0) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1841
#9 0x0000000000472c55 in gray_raster_render (raster=0x6ae800, params=0x7fffffffe1e0) at /usr/local/google/src/freetype2/src/smooth/ftgrays.c:1971
#10 0x00000000004732b1 in ft_smooth_render_generic (render=0x6ae730, slot=0x6aeed0, mode=FT_RENDER_MODE_NORMAL, origin=0x0, required_mode=FT_RENDER_MODE_NORMAL) at /usr/local/google/src/freetype2/src/smooth/ftsmooth.c:274
#11 0x000000000047352f in ft_smooth_render (render=0x6ae730, slot=0x6aeed0, mode=FT_RENDER_MODE_NORMAL, origin=0x0) at /usr/local/google/src/freetype2/src/smooth/ftsmooth.c:360
#12 0x000000000040b813 in FT_Render_Glyph_Internal (library=0x6a9040, slot=0x6aeed0, render_mode=FT_RENDER_MODE_NORMAL) at /usr/local/google/src/freetype2/src/base/ftobjs.c:3817
#13 0x000000000040b8e8 in FT_Render_Glyph (slot=0x6aeed0, render_mode=FT_RENDER_MODE_NORMAL) at /usr/local/google/src/freetype2/src/base/ftobjs.c:3857
#14 0x00000000004027ff in test_render (timer=0x7fffffffe460, face=0x6aeb40, user_data=0x0) at /usr/local/google/src/freetype2-demos/src/ftbench.c:269
#15 0x00000000004025a8 in benchmark (face=0x6aeb40, test=0x7fffffffe4d0, max_iter=1, max_time=2) at /usr/local/google/src/freetype2-demos/src/ftbench.c:188
#16 0x0000000000403876 in main (argc=1, argv=0x7fffffffe650) at /usr/local/google/src/freetype2-demos/src/ftbench.c:812

Robert Swiecki <jagger>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #20828:  sigsegv23.otf added by jagger (252kB - application/vnd.oasis.opendocument.formula-template)
file #20820:  sigsegv22.pfr added by jagger (30kB - application/octet-stream)

 

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
  • -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 10 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 01 Jul 2010 11:36:13 PM UTCwlAssigned tompsuzuki=>wl
    Wed 30 Jun 2010 04:25:11 PM UTCwlStatusWorks For Me=>Fixed
      Open/ClosedOpen=>Closed
      Planned ReleaseNone=>2.3.13
    Wed 30 Jun 2010 10:22:22 AM UTCwlAssigned towl=>mpsuzuki
    Mon 28 Jun 2010 07:30:44 PM UTCwlCarbon-Copy-=>Added mpsuzuki
    Sun 27 Jun 2010 12:59:36 AM UTCjaggerAttached File-=>Added sigsegv23.otf, #20828
    Sun 27 Jun 2010 12:43:54 AM UTCwlStatusNone=>Works For Me
      Assigned toNone=>wl
    Fri 25 Jun 2010 02:11:12 PM UTCjaggerAttached File-=>Added sigsegv22.pfr, #20820

    Back to the top


    Powered by Savane 3.1-cleanup