Re: [ft-devel] ftview crashes

[Andrey V. Panov]

On 13 марта 2009, Werner LEMBERG wrote:
> > It seems to be caused by gcc option -mtune=i686 for libfreetype
> > compilation, without it ftview does not crash.  In both cases I
> > combined it with -O2.  I compiled freetype on slackware 12.2 (x86
> > linux, gcc 4.2.4). The backtrace of ftview is:
> >
> > #0  0xb8062a0a in ftc_basic_family_load_bitmap (ftcfamily=0x8077790,
> > gindex=0, manager=0x8066670,
> >     aface=0xbfb9e018) at
> > /usr/local/src/freetype-2.3.9/src/cache/ftcbasic.c:164 164          
> > FT_Face  face = size->face;
>
> Please try compilation with -O0 -- the above line looks quite normal
> to me.  Can you also try valgrind?

freetype compiled with "-O0 -mtune=i686" does not cause a crash.
Output of valgrind for the crash is:

==10764== Memcheck, a memory error detector.
==10764== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==10764== Using LibVEX rev 1884, a library for dynamic binary translation.
==10764== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==10764== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==10764== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==10764== For more details, rerun with: -v
==10764== 
==10764== Use of uninitialised value of size 4
==10764==    at 0x407C4E1: FTC_Manager_LookupFace (ftcmanag.c:327)
==10764==    by 0x407C51D: ftc_basic_family_get_count (ftcbasic.c:141)
==10764==    by 0x407C916: ftc_snode_new (ftcsbits.c:215)
==10764==    by 0x407D373: FTC_Cache_NewNode (ftccache.c:454)
==10764==    by 0x407D69B: FTC_SBitCache_LookupScaler (ftcbasic.c:743)
==10764==    by 0x804CCDA: FTDemo_Index_To_Bitmap (ftcommon.c:801)
==10764==    by 0x804CE70: FTDemo_Draw_Index (ftcommon.c:932)
==10764==    by 0x804B11B: main (ftview.c:385)
==10764== 
==10764== Use of uninitialised value of size 4
==10764==    at 0x407C618: FTC_Manager_LookupSize (ftcmanag.c:201)
==10764==    by 0x407C9F5: ftc_basic_family_load_bitmap (ftcbasic.c:161)
==10764==    by 0x407C74D: ftc_snode_load (ftcsbits.c:124)
==10764==    by 0x407C997: ftc_snode_new (ftcsbits.c:236)
==10764==    by 0x407D373: FTC_Cache_NewNode (ftccache.c:454)
==10764==    by 0x407D69B: FTC_SBitCache_LookupScaler (ftcbasic.c:743)
==10764==    by 0x804CCDA: FTDemo_Index_To_Bitmap (ftcommon.c:801)
==10764==    by 0x804CE70: FTDemo_Draw_Index (ftcommon.c:932)
==10764==    by 0x804B11B: main (ftview.c:385)
==10764== 
==10764== Invalid read of size 4
==10764==    at 0x407CA0A: ftc_basic_family_load_bitmap (ftcbasic.c:164)
==10764==    by 0x407C74D: ftc_snode_load (ftcsbits.c:124)
==10764==    by 0x407C997: ftc_snode_new (ftcsbits.c:236)
==10764==    by 0x407D373: FTC_Cache_NewNode (ftccache.c:454)
==10764==    by 0x407D69B: FTC_SBitCache_LookupScaler (ftcbasic.c:743)
==10764==    by 0x804CCDA: FTDemo_Index_To_Bitmap (ftcommon.c:801)
==10764==    by 0x804CE70: FTDemo_Draw_Index (ftcommon.c:932)
==10764==    by 0x804B11B: main (ftview.c:385)
==10764==  Address 0xec835657 is not stack'd, malloc'd or (recently) free'd
==10764== 
==10764== Process terminating with default action of signal 11 (SIGSEGV): 
dumping core
==10764==  Access not within mapped region at address 0xEC835657
==10764==    at 0x407CA0A: ftc_basic_family_load_bitmap (ftcbasic.c:164)
==10764==    by 0x407C74D: ftc_snode_load (ftcsbits.c:124)
==10764==    by 0x407C997: ftc_snode_new (ftcsbits.c:236)
==10764==    by 0x407D373: FTC_Cache_NewNode (ftccache.c:454)
==10764==    by 0x407D69B: FTC_SBitCache_LookupScaler (ftcbasic.c:743)
==10764==    by 0x804CCDA: FTDemo_Index_To_Bitmap (ftcommon.c:801)
==10764==    by 0x804CE70: FTDemo_Draw_Index (ftcommon.c:932)
==10764==    by 0x804B11B: main (ftview.c:385)
==10764==  If you believe this happened as a result of a stack overflow in your
==10764==  program's main thread (unlikely but possible), you can try to 
increase
==10764==  the size of the main thread stack using the --main-stacksize= flag.
==10764==  The main thread stack size used in this run was 8388608.
==10764== 
==10764== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 35 from 1)
==10764== malloc/free: in use at exit: 5,715,495 bytes in 728 blocks.
==10764== malloc/free: 1,086 allocs, 358 frees, 5,767,792 bytes allocated.
==10764== For counts of detected errors, rerun with: -v
==10764== Use --track-origins=yes to see where uninitialised values come from
==10764== searching for pointers to 728 not-freed blocks.
==10764== checked 5,862,128 bytes.
==10764== 
==10764== LEAK SUMMARY:
==10764==    definitely lost: 0 bytes in 0 blocks.
==10764==      possibly lost: 0 bytes in 0 blocks.
==10764==    still reachable: 5,715,495 bytes in 728 blocks.
==10764==         suppressed: 0 bytes in 0 blocks.
==10764== Rerun with --leak-check=full to see details of leaked memory.



-- 
Andrey V. Panov
panov /@/ canopus.iacp.dvo.ru