Re: [PATCH] Fix font rendering error in FreeType 2.8.1 update, memory allocation related?

[Bryan Linton]

On 2018-03-11 18:03:27, Matthieu Herrb  wrote:
> On Sun, Mar 11, 2018 at 11:58:50AM +0900, Bryan Linton wrote:
> > [I sent a copy of this email to tech@ 24 hours ago and it hasn't
> > shown up yet.  Apologies if this ends up being a double-post.]
> > 
> > Hello tech@
> > 
> > I'm not sure if it's bad form to crosspost this from bugs@ to
> > tech@ or not, but I have a patch that fixes a font rendering issue
> > with the new FreeType 2.8.1 update that went in last December.
> > 
> > The beginning of the thread can be found at the following link.
> > It also includes a screenshot (linked at the very bottom of the
> > page) of how it manifests in an xterm.  FWIW, I also see the same
> > rendering issue in Firefox, so it's not just limited to the console:
> > https://marc.info/?l=openbsd-bugs=151835980313045=2
> > 
> > I managed to bisect things, and found that this one-line diff
> > fixes the issue for me.  It's a reversion back to the line of code
> > that was present in FreeType 2.8.0.
> 
> Thanks for bisecting the problem which apparently only happens for
> some specific fonts since I've not been able to reproduce it with any
> other font nor have I seen other reports of similar issues.
> 
> Did you try to report it upstreams ? (in the mean time Freetype 2.9
> has been released, but without change to this code.
> 

I have not reported this to upstream yet.  I see that you have
already done so in my stead though.  Thank you for doing so.

> Reading the commit bd28952e23bcd268a623ea5202e1cde4a92defe4 from
> upstreams they seem to assume that the memory allocated by
> memory->alloc() is already zeroed. The original but report is
> https://savannah.nongnu.org/bugs/?51816
> 
> Does an explicit zeroing like in the patch below also fix the issue
> for you ?
> 

Yes, I can confirm that your patch fixes this issue for me.  Thank
you very much for looking into this for me.

-- 
Bryan

Re: [PATCH] Fix font rendering error in FreeType 2.8.1 update, memory allocation related?

[Matthieu Herrb]

On Sun, Mar 11, 2018 at 11:58:50AM +0900, Bryan Linton wrote:
> [I sent a copy of this email to tech@ 24 hours ago and it hasn't
> shown up yet.  Apologies if this ends up being a double-post.]
> 
> Hello tech@
> 
> I'm not sure if it's bad form to crosspost this from bugs@ to
> tech@ or not, but I have a patch that fixes a font rendering issue
> with the new FreeType 2.8.1 update that went in last December.
> 
> The beginning of the thread can be found at the following link.
> It also includes a screenshot (linked at the very bottom of the
> page) of how it manifests in an xterm.  FWIW, I also see the same
> rendering issue in Firefox, so it's not just limited to the console:
>   https://marc.info/?l=openbsd-bugs=151835980313045=2
> 
> I managed to bisect things, and found that this one-line diff
> fixes the issue for me.  It's a reversion back to the line of code
> that was present in FreeType 2.8.0.

Thanks for bisecting the problem which apparently only happens for
some specific fonts since I've not been able to reproduce it with any
other font nor have I seen other reports of similar issues.

Did you try to report it upstreams ? (in the mean time Freetype 2.9
has been released, but without change to this code.

Reading the commit bd28952e23bcd268a623ea5202e1cde4a92defe4 from
upstreams they seem to assume that the memory allocated by
memory->alloc() is already zeroed. The original but report is
https://savannah.nongnu.org/bugs/?51816

Does an explicit zeroing like in the patch below also fix the issue
for you ?

Otherwise something else is wrong and reverting that commit is
probably just hiding a more serious issue. I must admit that I hate
the Freetype coding style and have difficulties reading their code.

Index: src/base/ftutil.c
===
RCS file: /cvs/OpenBSD/xenocara/lib/freetype/src/base/ftutil.c,v
retrieving revision 1.9
diff -u -r1.9 ftutil.c
--- src/base/ftutil.c   15 Dec 2017 19:29:12 -  1.9
+++ src/base/ftutil.c   11 Mar 2018 17:00:53 -
@@ -146,6 +146,7 @@
   block = memory->alloc( memory, new_count * item_size );
   if ( block == NULL )
 error = FT_THROW( Out_Of_Memory );
+  FT_MEM_ZERO( block, new_count * item_size );
 }
 else
 {

-- 
Matthieu Herrb