Hi, Since I installed fontconfig from branch, I''m experiencing memory problems with firefox. I cannot reproduce this without branch, but almost always happens with. I went back on branch to 2004-11-29, happenning still. With firefox, when exiting, I get the following glibc-detected invalid pointer: ======= Backtrace: ========/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] ... I also valgrinded pango/examples/pango-cairoview. With branch, I get this: ==15686===15686== Syscall param write(buf) points to uninitialised byte(s) ==15686== at 0x6F6B03: __write_nocancel (in /lib/libc-2.3.5.so) ==15686== by 0x1BAC2485: FcConfigBuildFonts (fccfg.c:328) ==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) ==15686== by 0x1B920A56: pango_font_map_load_fontset (pango-fontmap.c:106) ==15686== by 0x1B91EEC2: itemize_state_process_run (pango-context.c:1046) ==15686== by 0x1B91F899: pango_itemize_with_base_dir (pango-context.c:1190) ==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) ==15686= Maybe someone has any idea? --behdad http://behdad.org/ "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill" -- Dan Bern, "New American Language"
On Sunday 04 December 2005 07:08, Behdad Esfahbod wrote:> Hi, > > Since I installed fontconfig from branch, I''m experiencing memory > problems with firefox. I cannot reproduce this without branch, > but almost always happens with. I went back on branch to > 2004-11-29, happenning still. > > With firefox, when exiting, I get the following glibc-detected > invalid pointer: > > ======= Backtrace: ========> /lib/libc.so.6[0xdc7124] > /lib/libc.so.6(__libc_free+0x77)[0xdc765f] > /home/behdad/.local/lib/libfontconfig.so.1(FcValueListDestroy+0x1d0)[0x7172 >ec] > /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] > ... > > > I also valgrinded pango/examples/pango-cairoview. With branch, I > get this: >The valgrind log is pretty much meaningless and just a warning. Do you get a crash with the pango example too? Or a valgrind hit with firefox? I have no problems whatsoever with firefox and the fontconfig CVS. But then again I have a newer firefox version. Greetings, Stephan -- Pace Peace Paix Paz Frieden Pax Pok?j Fri?ur Fred B?ke ?? Hasiti Lap? Hetep Malu M?? Wolakota Santiphap Irini Peoch Shanti Vrede Baris R?j M?r Taika Rongo Sulh Py''guapy ??
On Sun, 4 Dec 2005, Stephan Kulow wrote:> The valgrind log is pretty much meaningless and just a warning.Any reason that you think so? I''ve very rarely seen valgrind being wrong.> Do you get a crash with the pango example too?No, but then again, I don''t get a crash with most of problems that I find using valgrind and fix.> Or a valgrind hit with firefox?valgrinding firefox takes just too long to try. :(> I have no problems whatsoever with firefox and the fontconfig > CVS. But then again I have a newer firefox version.If I slightly change my configuration, to use different fonts, I don''t get any crashes. That''s basically how memory problems are. If you don''t get hit, doesn''t mean it''s not there.> Greetings, Stephan--behdad http://behdad.org/ "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill" -- Dan Bern, "New American Language"
On Sunday 04 December 2005 09:48, Behdad Esfahbod wrote:> On Sun, 4 Dec 2005, Stephan Kulow wrote: > > The valgrind log is pretty much meaningless and just a warning. > > Any reason that you think so? I''ve very rarely seen valgrind > being wrong.Sure, but it''s a warning. And the warning says that the file written to disc contains uninitialized bytes. But valgrind can''t say if these bytes have any meaning and for sure it''s no direct reason to crash. So I say it''s meaningless in that context.> > > Do you get a crash with the pango example too? > > No, but then again, I don''t get a crash with most of problems > that I find using valgrind and fix.But it shows that the problem is within firefox. It uses the API in a way that is used nowhere else.> > > Or a valgrind hit with firefox? > > valgrinding firefox takes just too long to try. :(Hmm, you wouldn''t want to read your gmail with it, but it should startup in a reasonable time :)> > > I have no problems whatsoever with firefox and the fontconfig > > CVS. But then again I have a newer firefox version. > > If I slightly change my configuration, to use different fonts, I > don''t get any crashes. That''s basically how memory problems are. > If you don''t get hit, doesn''t mean it''s not there.No reason to tell me about it - I have valgrind test cases named after me ;) Geetings, Stephan -- Pace Peace Paix Paz Frieden Pax Pok?j Fri?ur Fred B?ke ?? Hasiti Lap? Hetep Malu M?? Wolakota Santiphap Irini Peoch Shanti Vrede Baris R?j M?r Taika Rongo Sulh Py''guapy ??
On Sun, 4 Dec 2005, Stephan Kulow wrote:> On Sunday 04 December 2005 09:48, Behdad Esfahbod wrote: > > On Sun, 4 Dec 2005, Stephan Kulow wrote: > > > The valgrind log is pretty much meaningless and just a warning. > > > > Any reason that you think so? I''ve very rarely seen valgrind > > being wrong. > > Sure, but it''s a warning. And the warning says that the file written to > disc contains uninitialized bytes. But valgrind can''t say if these bytes > have any meaning and for sure it''s no direct reason to crash. So I say > it''s meaningless in that context.Right.> > > Do you get a crash with the pango example too? > > > > No, but then again, I don''t get a crash with most of problems > > that I find using valgrind and fix. > > But it shows that the problem is within firefox. It uses the API in a > way that is used nowhere else. > > > > Or a valgrind hit with firefox? > > > > valgrinding firefox takes just too long to try. :( > Hmm, you wouldn''t want to read your gmail with it, but it should startup > in a reasonable time :)Did it three times, none hit the problem :(.> > > I have no problems whatsoever with firefox and the fontconfig > > > CVS. But then again I have a newer firefox version. > > > > If I slightly change my configuration, to use different fonts, I > > don''t get any crashes. That''s basically how memory problems are. > > If you don''t get hit, doesn''t mean it''s not there. > No reason to tell me about it - I have valgrind test cases named after me ;)Ok, it was just GIGO ;).> Geetings, StephanCheers, --behdad
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
On Mon, 5 Dec 2005, Patrick Lam wrote:> 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?)I attached a debugger and the pointer indeed points to a font name, "Nimbus something" in this case. More below.> 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.Ok, cvs up''ed, make clean, reconfigure with gcc -g -O0, make, make install, fc-cache. glibc backtrace: *** glibc detected *** /usr/lib/firefox-1.0.7/firefox-bin: free(): invalid pointer: 0x0a02d080 *** ======= Backtrace: ========/lib/libc.so.6[0x100f124] /lib/libc.so.6(__libc_free+0x77)[0x100f65f] /home/behdad/.local/lib/libfontconfig.so.1(FcStrFree+0x46)[0x74df8e] /home/behdad/.local/lib/libfontconfig.so.1(FcValueListDestroy+0x74)[0x749414] /home/behdad/.local/lib/libfontconfig.so.1(FcPatternDestroy+0xb8)[0x749bbc] and gdb: (gdb) bt #0 0x005d1402 in __kernel_vsyscall () #1 0x00e2e118 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67 #2 0x00e2f888 in *__GI_abort () at ../sysdeps/generic/abort.c:88 #3 0x00e6322a in __libc_message (do_abort=2, fmt=0xf201c0 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:170 #4 0x00e69124 in _int_free (av=0xf2c880, mem=0x8e83340) at malloc.c:5578 #5 0x00e6965f in *__GI___libc_free (mem=0x8e83340) at malloc.c:3419 #6 0x008b0f8e in FcStrFree (s=0x8e83340 "Nimbus Roman No9 L") at fcstr.c:63 #7 0x008ac414 in FcValueListDestroy (l {bank = 0, u = {stat = 149435064, dyn = 0x8e832b8}}) at fcpat.c:153 #8 0x008acbbc in FcPatternDestroy (p=0x8e60d68) at fcpat.c:318 #9 0x0209f746 in NSGetModule () from /usr/lib/firefox-1.0.7/components/libgfx_gtk.so #10 0x0209f97a in NSGetModule () from /usr/lib/firefox-1.0.7/components/libgfx_gtk.so So, no, it''s not the line you pointed at, but the one in case FcTypeString. --behdad http://behdad.org/ "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill" -- Dan Bern, "New American Language"
Behdad Esfahbod wrote:> *** glibc detected *** /usr/lib/firefox-1.0.7/firefox-bin: > free(): invalid pointer: 0x0a02d080 ***I think that this patch ought to fix the problem: Index: src/fcpat.c ==================================================================RCS file: /cvs/fontconfig/fontconfig/src/fcpat.c,v retrieving revision 1.27.2.27 diff -u -p -r1.27.2.27 fcpat.c --- src/fcpat.c 29 Nov 2005 06:09:18 -0000 1.27.2.27 +++ src/fcpat.c 5 Dec 2005 06:57:09 -0000 @@ -36,6 +36,8 @@ static int fcvaluelist_bank_count = 0, f static FcPatternEltPtr FcPatternEltPtrCreateDynamic (FcPatternElt * e); +static FcBool +FcStrHashed (const FcChar8 *name); static const char * FcPatternFindFullFname (const FcPattern *p); @@ -69,7 +71,8 @@ FcValueDestroy (FcValue v) { switch (v.type) { case FcTypeString: - FcStrFree ((FcChar8 *) v.u.s); + if (!FcStrHashed (v.u.s)) + FcStrFree ((FcChar8 *) v.u.s); break; case FcTypeMatrix: FcMatrixFree ((FcMatrix *) v.u.m); @@ -150,7 +153,8 @@ FcValueListDestroy (FcValueListPtr l) { switch (FcValueListPtrU(l)->value.type) { case FcTypeString: - FcStrFree ((FcChar8 *)FcValueListPtrU(l)->value.u.s); + if (!FcStrHashed ((FcChar8 *)FcValueListPtrU(l)->value.u.s)) + FcStrFree ((FcChar8 *)FcValueListPtrU(l)->value.u.s); break; case FcTypeMatrix: FcMatrixFree ((FcMatrix *)FcValueListPtrU(l)->value.u.m); @@ -1365,6 +1369,19 @@ static struct objectBucket { FcChar32 hash; } *FcObjectBuckets[OBJECT_HASH_SIZE]; +static FcBool +FcStrHashed (const FcChar8 *name) +{ + FcChar32 hash = FcStringHash (name); + struct objectBucket **p; + struct objectBucket *b; + + for (p = &FcObjectBuckets[hash % OBJECT_HASH_SIZE]; (b = *p); p = &(b->next)) + if (b->hash == hash && !strcmp ((char *)name, (char *) (b + 1))) + return FcTrue; + return FcFalse; +} + const FcChar8 * FcStrStaticName (const FcChar8 *name) { Please test it; if it works, I''ll commit it. pat