I submitted this bug to the fontconfig mailing list, here's the answer: http://lists.freedesktop.org/archives/fontconfig/2014-January/005044.html
From: Akira TAGOH <ak...@tagoh.org> Date: 2014/1/6 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
