GNU bug report logs - #41627
28.0.50; Emacs with cairo build segfault in HELLO file

Previous Next

Full log

Message #35 received at 41627 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 41627 <at> debbugs.gnu.org, all_but_last <at> 163.com
Subject: Re: bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file
Date: Mon, 1 Jun 2020 18:02:12 +0000

On Mon, Jun 1, 2020 at 4:35 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Pip Cet <pipcet <at> gmail.com>
> > Date: Sun, 31 May 2020 20:45:56 +0000
> > Cc: Zihao Zhu <all_but_last <at> 163.com>, 41627 <at> debbugs.gnu.org
> >
> > > Can someone please propose a patch along these lines?  I cannot easily
> > > test a Cairo build, so I won't try showing a patch.
> >
> > How about this?
>
> LGTM, thanks.  I gather that you tested this bail-out, and saw that it
> does TRT (probably skipping the problematic font)?

Yes, I did, but I'd really like to corrupt some font files and test
further. I think there might be more resource leaks there.

> > (I'm not sure how and whether `match' is supposed to be freed in the
> > success case, or whether it's simply leaked).
>
> From some code fragments I see on the net, I think you are right, and
> we should free it before returning.

I tried doing that in the debugger, and there was no immediate
segfault, for all that's worth. By now I've downloaded fontconfig...

> Btw, there are more calls to cairo_ft_scaled_font_lock_face in our
> code followed by unconditional dereference of the result...

As I said, "I suspect the attached patch will work, but if this is
something Cairo does in other places it needs to be checked." Some
initial investigation reveals that yes, Cairo does it all over the
place.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.