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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 41627 in the body.
You can then email your comments to 41627 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Zihao Zhu <all_but_last <at> 163.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Emacs with cairo build segfault in HELLO file
Date: Sun, 31 May 2020 19:32:18 +0800

[Message part 1 (text/plain, inline)]

I try the Emacs build in commit 
780f674a82a90c4e3e32583059b498bfa57e4a06. When I eval

(set-frame-font "Sarasa Mono Slab SC" t)

then run M-x view-hello-file. Emacs segfault.

Sarasa Gothic: https://github.com/be5invis/Sarasa-Gothic

GDB attached backtrace in attachment.

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
3.24.14, cairo version 1.16.0)
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Arch Linux

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Configured using:
 'configure
 CONFIG_SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash
 SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash
 --prefix=/gnu/store/18644azvqlk7kn7i7cfl5z9w5535l0dg-emacs-git-28.0.50-0.780f674
 --enable-fast-install --with-harfbuzz --with-modules
 --disable-build-details'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS JSON PDUMPER
GMP

Important settings:
  value of $EMACSLOADPATH: 
/home/chino/.guix-profile/share/emacs/site-lisp:/home/chino/.guix-profile/share/emacs/28.0.50/lisp
  value of $LC_CTYPE: en_US.UTF-8
  value of $LANG: zh_CN.UTF-8
  value of $XMODIFIERS: @im=fcitx
  locale-coding-system: utf-8-unix


Memory information:
((conses 16 47059 5207)
 (symbols 48 5994 1)
 (strings 32 16196 1908)
 (string-bytes 1 527713)
 (vectors 16 10973)
 (vector-slots 8 134648 8501)
 (floats 8 19 34)
 (intervals 56 226 0)
 (buffers 992 12))

-- 
Zihao

[gdb-backtrace.txt (text/plain, attachment)]

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

From: Pip Cet <pipcet <at> gmail.com>
To: Zihao Zhu <all_but_last <at> 163.com>
Cc: 41627 <at> debbugs.gnu.org
Subject: Re: bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file
Date: Sun, 31 May 2020 12:35:07 +0000

[Message part 1 (text/plain, inline)]

On Sun, May 31, 2020 at 11:49 AM Zihao Zhu <all_but_last <at> 163.com> wrote:
> I try the Emacs build in commit
> 780f674a82a90c4e3e32583059b498bfa57e4a06. When I eval
>
> (set-frame-font "Sarasa Mono Slab SC" t)

> GDB attached backtrace in attachment.

This line seems suspicious:

        font_face = 0x7ffff747e880 <_cairo_font_face_nil_file_not_found>

It looks like you can't rely on cairo_ft_font_face_create_for_pattern
to return a NULL pointer. I suspect the attached patch will work, but
if this is something Cairo does in other places it needs to be
checked.

(My suspicion is the font was not installed correctly, so Cairo
couldn't find it.)

[0001-Handle-the-case-that-Cairo-cannot-find-a-font-file-B.patch (text/x-patch, attachment)]

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

From: Zihao Zhu <all_but_last <at> 163.com>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 41627 <at> debbugs.gnu.org
Subject: Re: bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file
Date: Sun, 31 May 2020 22:27:35 +0800

I think if font was not installed correctly, Emacs should display "tofu" 
for unsupported chars, but it will display it and segfault.

And I also found that Emacs can work well in ASCII and CJK only 
environment(Sarasa font). But segfault in HELLO file and any other 
multi-language buffer which Emacs will choose Noto family to display.

On 2020/5/31 下午8:35, Pip Cet wrote:
> On Sun, May 31, 2020 at 11:49 AM Zihao Zhu <all_but_last <at> 163.com> wrote:
>> I try the Emacs build in commit
>> 780f674a82a90c4e3e32583059b498bfa57e4a06. When I eval
>>
>> (set-frame-font "Sarasa Mono Slab SC" t)
>> GDB attached backtrace in attachment.
> This line seems suspicious:
>
>          font_face = 0x7ffff747e880 <_cairo_font_face_nil_file_not_found>
>
> It looks like you can't rely on cairo_ft_font_face_create_for_pattern
> to return a NULL pointer. I suspect the attached patch will work, but
> if this is something Cairo does in other places it needs to be
> checked.
>
> (My suspicion is the font was not installed correctly, so Cairo
> couldn't find it.)

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

From: Zihao Zhu <all_but_last <at> 163.com>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 41627 <at> debbugs.gnu.org
Subject: Re: bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file
Date: Sun, 31 May 2020 22:31:37 +0800

I don't understand why fonts are not correctly installed. The return 
value of (x-list-fonts "*")  contains Sarasa font and Noto fonts. Looks 
that Emacs detect these font successfully.

On 2020/5/31 下午8:35, Pip Cet wrote:
> On Sun, May 31, 2020 at 11:49 AM Zihao Zhu <all_but_last <at> 163.com> wrote:
>> I try the Emacs build in commit
>> 780f674a82a90c4e3e32583059b498bfa57e4a06. When I eval
>>
>> (set-frame-font "Sarasa Mono Slab SC" t)
>> GDB attached backtrace in attachment.
> This line seems suspicious:
>
>          font_face = 0x7ffff747e880 <_cairo_font_face_nil_file_not_found>
>
> It looks like you can't rely on cairo_ft_font_face_create_for_pattern
> to return a NULL pointer. I suspect the attached patch will work, but
> if this is something Cairo does in other places it needs to be
> checked.
>
> (My suspicion is the font was not installed correctly, so Cairo
> couldn't find it.)

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

From: Pip Cet <pipcet <at> gmail.com>
To: Zihao Zhu <all_but_last <at> 163.com>
Cc: 41627 <at> debbugs.gnu.org
Subject: Re: bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file
Date: Sun, 31 May 2020 14:34:29 +0000

On Sun, May 31, 2020 at 2:28 PM Zihao Zhu <all_but_last <at> 163.com> wrote:
> I think if font was not installed correctly, Emacs should display "tofu"
> for unsupported chars, but it will display it and segfault.

Yes, that's definitely a bug. I was just trying to warn you that
fixing this bug in Emacs would likely lead to the aforementioned tofu.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Zihao Zhu <all_but_last <at> 163.com>
Cc: 41627 <at> debbugs.gnu.org
Subject: Re: bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file
Date: Sun, 31 May 2020 17:54:30 +0300

> From: Zihao Zhu <all_but_last <at> 163.com>
> Date: Sun, 31 May 2020 19:32:18 +0800
> 
> I try the Emacs build in commit 
> 780f674a82a90c4e3e32583059b498bfa57e4a06. When I eval
> 
> (set-frame-font "Sarasa Mono Slab SC" t)
> 
> then run M-x view-hello-file. Emacs segfault.
> 
> Sarasa Gothic: https://github.com/be5invis/Sarasa-Gothic
> 
> GDB attached backtrace in attachment.

Thanks.  can you show a backtrace from an unoptimized build (assuming
it also crashes in this case)?

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

From: Zihao Zhu <all_but_last <at> 163.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 41627 <at> debbugs.gnu.org, Pip Cet <pipcet <at> gmail.com>
Subject: Re: bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file
Date: Sun, 31 May 2020 23:38:28 +0800

[Message part 1 (text/plain, inline)]

A gdb attached backtrace generated by Emacs build with CFLAGS=-O0 -g3 in 
attachment

On 2020/5/31 下午10:54, Eli Zaretskii wrote:
>> From: Zihao Zhu <all_but_last <at> 163.com>
>> Date: Sun, 31 May 2020 19:32:18 +0800
>>
>> I try the Emacs build in commit
>> 780f674a82a90c4e3e32583059b498bfa57e4a06. When I eval
>>
>> (set-frame-font "Sarasa Mono Slab SC" t)
>>
>> then run M-x view-hello-file. Emacs segfault.
>>
>> Sarasa Gothic: https://github.com/be5invis/Sarasa-Gothic
>>
>> GDB attached backtrace in attachment.
> Thanks.  can you show a backtrace from an unoptimized build (assuming
> it also crashes in this case)?

[gdb.txt (text/plain, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Zihao Zhu <all_but_last <at> 163.com>
Cc: 41627 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: Re: bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file
Date: Sun, 31 May 2020 20:24:41 +0300

> Cc: 41627 <at> debbugs.gnu.org, Pip Cet <pipcet <at> gmail.com>
> From: Zihao Zhu <all_but_last <at> 163.com>
> Date: Sun, 31 May 2020 23:38:28 +0800
> 
> A gdb attached backtrace generated by Emacs build with CFLAGS=-O0 -g3 in 
> attachment

Thanks, I think the situation is clear.

> 0x00000000006c5a34 in ftcrfont_open (f=0xc192d0, entity=0x1300675, pixel_size=18) at ftcrfont.c:237
> 237	ftcrfont.c: 没有那个文件或目录.
> #0  0x00000000006c5a34 in ftcrfont_open (f=0xc192d0, entity=0x1300675, pixel_size=18) at ftcrfont.c:237

This crashes here:

  ft_face = cairo_ft_scaled_font_lock_face (scaled_font);
  if (XFIXNUM (AREF (entity, FONT_SIZE_INDEX)) == 0)
    {
      int upEM = ft_face->units_per_EM;  <<<<<<<<<<<<<<<<<<<<<

because cairo_ft_scaled_font_lock_face returned NULL:

>         ft_face = 0x0

That function is documented to be able to return NULL:

  Returns

  The FT_Face object for font, scaled appropriately, or NULL if
  scaled_font is in an error state (see cairo_scaled_font_status()) or
  there is insufficient memory.

So it sounds like we should see if scaled_font is "in an error state",
and in any case bail out if ft_face is NULL.

Can someone please propose a patch along these lines?  I cannot easily
test a Cairo build, so I won't try showing a patch.

Thanks.

Message #29 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, Zihao Zhu <all_but_last <at> 163.com>
Subject: Re: bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file
Date: Sun, 31 May 2020 20:45:56 +0000

[Message part 1 (text/plain, inline)]

On Sun, May 31, 2020 at 5:24 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> 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?

(I'm not sure how and whether `match' is supposed to be freed in the
success case, or whether it's simply leaked).

[0001-Handle-Cairo-errors-in-ftcrfont_open-bug-41627.patch (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
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, 01 Jun 2020 19:35:18 +0300

> 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)?

> (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.

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

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.

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

From: "Zhu Zihao" <all_but_last <at> 163.com>
To: 41627 <at> debbugs.gnu.org
Cc: eliz <at> gnu.org
Subject: Re: bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file
Date: Tue, 23 Jun 2020 00:47:30 +0800 (CST)

[Message part 1 (text/plain, inline)]

I'm able to reproduce this bug in NixOS 20.03 with Emacs 27.0.91 pretest version. I guess this bug is caused by the mechanism of Nix/Guix. NixOS doesn't have FHS directory structure, it means that there's nothing like /usr/share/fonts for Cairo to search fonts. And I try to copy some fonts to ~/.local/share/fonts then Emacs won't crash again.

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Zhu Zihao" <all_but_last <at> 163.com>
Cc: 41627 <at> debbugs.gnu.org
Subject: Re: bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file
Date: Mon, 22 Jun 2020 21:06:41 +0300

> Date: Tue, 23 Jun 2020 00:47:30 +0800 (CST)
> From: "Zhu Zihao" <all_but_last <at> 163.com>
> Cc: eliz <at> gnu.org
> 
> I'm able to reproduce this bug in NixOS 20.03 with Emacs 27.0.91 pretest version. I guess this bug is
> caused by the mechanism of Nix/Guix. NixOS doesn't have FHS directory structure, it means that there's
> nothing like /usr/share/fonts for Cairo to search fonts. And I try to copy some fonts to ~/.local/share/fonts
> then Emacs won't crash again.

If you can show a backtrace from the crash, perhaps we could find the
reason and fix it.

Thanks.

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

From: "Zhu Zihao" <all_but_last <at> 163.com>
To: "Eli Zaretskii" <eliz <at> gnu.org>
Cc: 41627 <at> debbugs.gnu.org
Subject: Re:Re: bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO
 file
Date: Tue, 23 Jun 2020 12:10:54 +0800 (CST)

[Message part 1 (text/plain, inline)]

But it's sad that I can't reproduce that bug in NixOS :(





















At 2020-06-23 02:06:41, "Eli Zaretskii" <eliz <at> gnu.org> wrote:
>> Date: Tue, 23 Jun 2020 00:47:30 +0800 (CST)
>> From: "Zhu Zihao" <all_but_last <at> 163.com>
>> Cc: eliz <at> gnu.org
>> 
>> I'm able to reproduce this bug in NixOS 20.03 with Emacs 27.0.91 pretest version. I guess this bug is
>> caused by the mechanism of Nix/Guix. NixOS doesn't have FHS directory structure, it means that there's
>> nothing like /usr/share/fonts for Cairo to search fonts. And I try to copy some fonts to ~/.local/share/fonts
>> then Emacs won't crash again.
>
>If you can show a backtrace from the crash, perhaps we could find the
>reason and fix it.
>
>Thanks.

[Message part 2 (text/html, inline)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 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: Sun, 27 Sep 2020 16:29:33 +0200

Pip Cet <pipcet <at> gmail.com> writes:

> 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.

Did you get any further here?  The posted patch wasn't applied, as far
as I can see, but would apparently have fixed the HELLO segfault, so
that seems worth it on its own (although the other calls to
cairo_ft_scaled_font_lock_face should also be fixed)...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 41627 <at> debbugs.gnu.org, all_but_last <at> 163.com,
 Pip Cet <pipcet <at> gmail.com>
Subject: Re: bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file
Date: Wed, 21 Oct 2020 17:58:30 +0200

>>>>> On Sun, 27 Sep 2020 16:29:33 +0200, Lars Ingebrigtsen <larsi <at> gnus.org> said:

    Lars> Pip Cet <pipcet <at> gmail.com> writes:
    >> 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.

    Lars> Did you get any further here?  The posted patch wasn't applied, as far
    Lars> as I can see, but would apparently have fixed the HELLO segfault, so
    Lars> that seems worth it on its own (although the other calls to
    Lars> cairo_ft_scaled_font_lock_face should also be fixed)...

All the other calls to cairo_ft_scaled_font_lock_face use the
cr_scaled_font member of the font_info passed in, which I think means
thatʼs only done for fonts which were opened successfully.

Robert
-- 

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 41627 <at> debbugs.gnu.org, all_but_last <at> 163.com,
 Pip Cet <pipcet <at> gmail.com>
Subject: Re: bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file
Date: Thu, 22 Oct 2020 13:41:21 +0200

Robert Pluim <rpluim <at> gmail.com> writes:

>     Lars> Did you get any further here?  The posted patch wasn't applied, as far
>     Lars> as I can see, but would apparently have fixed the HELLO segfault, so
>     Lars> that seems worth it on its own (although the other calls to
>     Lars> cairo_ft_scaled_font_lock_face should also be fixed)...
>
> All the other calls to cairo_ft_scaled_font_lock_face use the
> cr_scaled_font member of the font_info passed in, which I think means
> thatʼs only done for fonts which were opened successfully.

I see.  So I went ahead and applied Pip's patch to Emacs 28 (after
testing that HELLO still works), and I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Zhu Zihao <all_but_last <at> 163.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Robert Pluim <rpluim <at> gmail.com>, 41627 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>, Pip Cet <pipcet <at> gmail.com>
Subject: Re: bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file
Date: Thu, 22 Oct 2020 20:03:53 +0800

[Message part 1 (text/plain, inline)]

Any plan on a regression patch on Emacs 27?

Lars Ingebrigtsen writes:

> Robert Pluim <rpluim <at> gmail.com> writes:
>
>>     Lars> Did you get any further here?  The posted patch wasn't applied, as far
>>     Lars> as I can see, but would apparently have fixed the HELLO segfault, so
>>     Lars> that seems worth it on its own (although the other calls to
>>     Lars> cairo_ft_scaled_font_lock_face should also be fixed)...
>>
>> All the other calls to cairo_ft_scaled_font_lock_face use the
>> cr_scaled_font member of the font_info passed in, which I think means
>> thatʼs only done for fonts which were opened successfully.
>
> I see.  So I went ahead and applied Pip's patch to Emacs 28 (after
> testing that HELLO still works), and I'm closing this bug report.


-- 
Retrieve my public GPG key: https://meta.sr.ht/~citreu.pgp

Zihao

[signature.asc (application/pgp-signature, inline)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Zhu Zihao <all_but_last <at> 163.com>
Cc: Robert Pluim <rpluim <at> gmail.com>, 41627 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>, Pip Cet <pipcet <at> gmail.com>
Subject: Re: bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file
Date: Thu, 22 Oct 2020 14:43:23 +0200

Zhu Zihao <all_but_last <at> 163.com> writes:

> Any plan on a regression patch on Emacs 27?

Yes, it should be backported in a couple of days if there's no problems
with it on the trunk.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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