bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file

Zihao Zhu
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 (585K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file

Pip Cet
On Sun, May 31, 2020 at 11:49 AM Zihao Zhu <[hidden email]> 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 (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file

Zihao Zhu
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 <[hidden email]> 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.)




Reply | Threaded
Open this post in threaded view
|

bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file

Zihao Zhu
In reply to this post by Pip Cet
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 <[hidden email]> 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.)




Reply | Threaded
Open this post in threaded view
|

bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file

Pip Cet
In reply to this post by Zihao Zhu
On Sun, May 31, 2020 at 2:28 PM Zihao Zhu <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file

Eli Zaretskii
In reply to this post by Zihao Zhu
> From: Zihao Zhu <[hidden email]>
> 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)?



Reply | Threaded
Open this post in threaded view
|

bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file

Zihao Zhu
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 <[hidden email]>
>> 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 (111K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file

Eli Zaretskii
> Cc: [hidden email], Pip Cet <[hidden email]>
> From: Zihao Zhu <[hidden email]>
> 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.



Reply | Threaded
Open this post in threaded view
|

bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file

Pip Cet
On Sun, May 31, 2020 at 5:24 PM Eli Zaretskii <[hidden email]> 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 (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file

Eli Zaretskii
> From: Pip Cet <[hidden email]>
> Date: Sun, 31 May 2020 20:45:56 +0000
> Cc: Zihao Zhu <[hidden email]>, [hidden email]
>
> > 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...



Reply | Threaded
Open this post in threaded view
|

bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file

Pip Cet
On Mon, Jun 1, 2020 at 4:35 PM Eli Zaretskii <[hidden email]> wrote:

> > From: Pip Cet <[hidden email]>
> > Date: Sun, 31 May 2020 20:45:56 +0000
> > Cc: Zihao Zhu <[hidden email]>, [hidden email]
> >
> > > 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.



Reply | Threaded
Open this post in threaded view
|

bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file

Zihao Zhu
In reply to this post by Zihao Zhu

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.



 

Reply | Threaded
Open this post in threaded view
|

bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file

Eli Zaretskii
> Date: Tue, 23 Jun 2020 00:47:30 +0800 (CST)
> From: "Zhu Zihao" <[hidden email]>
> Cc: [hidden email]
>
> 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.



Reply | Threaded
Open this post in threaded view
|

bug#41627: Re: bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file

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








At 2020-06-23 02:06:41, "Eli Zaretskii" <[hidden email]> wrote: >> Date: Tue, 23 Jun 2020 00:47:30 +0800 (CST) >> From: "Zhu Zihao" <[hidden email]> >> Cc: [hidden email] >> >> 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.


 

Reply | Threaded
Open this post in threaded view
|

bug#41627: 28.0.50; Emacs with cairo build segfault in HELLO file

Lars Ingebrigtsen
In reply to this post by Pip Cet
Pip Cet <[hidden email]> 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