[Fontconfig] This memory leak has been already patched?

[Akira TAGOH]

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 at gmail.com> 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/fontconfig



-- 
Akira TAGOH