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 _______________________________________________ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
