I'm not sure what exactly that patch fixes... >--- fontconfig-2.8.0/src/fcmatch.c 2009-11-16 22:46:18.000000000 +0000 >+++ src/fontconfig-2.8.0/src/fcmatch.c 2012-01-15 18:03:11.000000000 +0000 >@@ -552,6 +552,7 @@ > if (best) > return FcFontRenderPrepare (config, p, best); > else >+ FcPatternDestroy(best); > return NULL; That change doesn't take any effects. >--- fontconfig-2.8.0/src/fcpat.c 2009-11-16 22:46:18.000000000 +0000 >+++ src/fontconfig-2.8.0/src/fcpat.c 2012-01-15 20:27:07.000000000 +0000 >@@ -361,6 +361,8 @@ > e = malloc(s * sizeof (FcPatternElt)); > if (e) > memcpy(e, e0, p->num * sizeof (FcPatternElt)); >+ else if (!e) >+ return FcFalse; > } > } > else It do the same thing later. > bail2: >+ FcPatternDestroy(p); > FcValueDestroy (value); How come the p needs to be destroyed here? that should be the application bug if it's the cause of the memory leak. > bail1: > FcMemFree (FC_MEM_VALLIST, sizeof (FcValueList)); >- free (new); >+ FcValueListDestroy(new); > bail0: > return FcFalse; > } calling FcValueListDestroy should be overkill because no FcValue to destroy when coming from bail1 and bail2 because no FcValue to destroy from bail1 and value is already destroyed the above from bail2. if there are any way to reproduce this leak, that would be nice though. On Sun, Dec 22, 2013 at 9:36 AM, BubuXP <bubuxp@xxxxxxxxx> wrote: > Here is the bug report: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655989 > > That bug is not closed yet, maybe that leak is still present? > _______________________________________________ > Fontconfig mailing list > Fontconfig@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/fontconfig -- Akira TAGOH _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
