Hi Behdad, Behdad Esfahbod wrote: > /lib/libc.so.6[0xdc7124] > /lib/libc.so.6(__libc_free+0x77)[0xdc765f] > /home/behdad/.local/lib/libfontconfig.so.1(FcValueListDestroy+0x1d0)[0x7172ec] > /home/behdad/.local/lib/libfontconfig.so.1(FcPatternDestroy+0x155)[0x717750] > /usr/lib/firefox-1.0.7/components/libgfx_gtk.so[0x3f4a746] > /usr/lib/firefox-1.0.7/components/libgfx_gtk.so[0x3f4a97a] > /usr/lib/firefox-1.0.7/components/libgfx_gtk.so[0x3f4b698] > /usr/lib/firefox-1.0.7/components/libgfx_gtk.so[0x3f4ea73] Is it an invalid pointer rather than, say, a double free? I'd be interested in knowing what the pointer actually looks like (i.e. is it like 0, or like some number which obviously isn't a pointer, like 0x25?) This should never happen, because here .bank is saying that it's a dynamic FcValueListPtr and .u.dyn is not actually a pointer. The code at fault has to be, if (l.bank == FC_BANK_DYNAMIC) free(l.u.dyn); unless something is getting inlined. Installing fontconfig compiled with -O0 would actually be helpful here, too, just so that I know it's actually FcValueListDestroy and not one of its callees. > I also valgrinded pango/examples/pango-cairoview. With branch, I > get this: > > ==15686== Address 0x1BE93AA0 is 6264 bytes inside a block of size 25876 alloc'd > ==15686== at 0x1B909222: malloc (vg_replace_malloc.c:130) > ==15686== by 0x1BABDAEC: FcDirCacheProduce (fccache.c:823) > ==15686== by 0x1BABDBFE: FcGlobalCacheUpdate (fccache.c:304) > ==15686== by 0x1BAC7D6D: FcDirScanConfig (fcdir.c:190) > ==15686== by 0x1BAC2412: FcConfigBuildFonts (fccfg.c:304) > ==15686== by 0x1BACB30C: FcInitLoadConfigAndFonts (fcinit.c:85) > ==15686== by 0x1BACB5A5: FcInit (fcinit.c:103) > ==15686== by 0x1BABFD51: FcConfigGetCurrent (fccfg.c:360) > ==15686== by 0x1BAC3E9D: FcConfigSubstituteWithPat (fccfg.c:1278) > ==15686== by 0x1BAC3F00: FcConfigSubstitute (fccfg.c:1490) > ==15686== by 0x1B972BAB: pango_cairo_fc_font_map_context_substitute (pangocairo-fcfontmap.c:94) > ==15686== by 0x1B94E427: pango_fc_font_map_load_fontset (pangofc-fontmap.c:958) As Stephen says, I'm pretty sure this is unrelated to the crash; it's just because some bytes are skipped over in the global cache. pat
