GNU bug report logs - #49066
26.3; Segmentation fault on specific utf8 string

Previous Next

Full log

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 49066 <at> debbugs.gnu.org, larsi <at> gnus.org, mvsfrasson <at> gmail.com
Subject: Re: bug#49066: 26.3; Segmentation fault on specific utf8 string
Date: Thu, 17 Jun 2021 15:07:18 +0200

>>>>> On Thu, 17 Jun 2021 11:13:17 +0300, Eli Zaretskii <eliz <at> gnu.org> said:

    >> From: Robert Pluim <rpluim <at> gmail.com>
    >> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,  49066 <at> debbugs.gnu.org,
    >> mvsfrasson <at> gmail.com
    >> Date: Thu, 17 Jun 2021 09:43:03 +0200
    >> 
    >> This is from an optimized build of emacs-26.1. I can redo it with a
    >> '-g3 -O0' if you want.

    Eli> That'd help.

Full backtrace from an unoptimized build:

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x0000000000557a9d in AREF (array=XIL(0), idx=1) at lisp.h:1614
1614	  return XVECTOR (array)->contents[idx];
(gdb) bt
#0  0x0000000000557a9d in AREF (array=XIL(0), idx=1) at lisp.h:1614
#1  0x0000000000693602 in ftfont_shape_by_flt
    (lgstring=XIL(0xb64755), font=0x1308cb0 <bss_sbrk_buffer+8590480>, ft_face=0x340fef0, otf=0x342c810, matrix=0x1308da8 <bss_sbrk_buffer+8590728>) at ftfont.c:2573
#2  0x00000000006939c4 in ftfont_shape (lgstring=XIL(0xb64755)) at ftfont.c:2615
#3  0x0000000000695ae8 in xftfont_shape (lgstring=XIL(0xb64755)) at xftfont.c:670
#4  0x0000000000624f14 in Ffont_shape_gstring (gstring=XIL(0xb64755)) at font.c:4427
#5  0x000000000060714d in funcall_subr (subr=0xa41d60 <Sfont_shape_gstring>, numargs=1, args=0x7fffffff6830) at eval.c:2844
#6  0x0000000000606d80 in Ffuncall (nargs=2, args=0x7fffffff6828) at eval.c:2769
#7  0x000000000064ef3a in exec_byte_code
    (bytestr=XIL(0x81e114), vector=XIL(0x81e135), maxdepth=make_number(6), args_template=XIL(0), nargs=0, args=0x0) at bytecode.c:629
#8  0x0000000000607b03 in funcall_lambda (fun=XIL(0x81e0a5), nargs=5, arg_vector=0x81e135 <pure+964437>) at eval.c:3052
#9  0x0000000000606dc4 in Ffuncall (nargs=6, args=0x7fffffff6d20) at eval.c:2771
#10 0x000000000060392c in internal_condition_case_n (bfun=0x606c02 <Ffuncall>, nargs=6, args=0x7fffffff6d20, handlers=XIL(0xc090), hfun=
    0x43f2a4 <safe_eval_handler>) at eval.c:1412
#11 0x000000000043f519 in safe__call (inhibit_quit=false, nargs=6, func=XIL(0x8e6520), ap=0x7fffffff6e00) at xdisp.c:2617
#12 0x000000000043f60c in safe_call (nargs=6, func=XIL(0x8e6520)) at xdisp.c:2633
#13 0x000000000067e4e6 in autocmp_chars
    (rule=XIL(0xf2b705), charpos=40, bytepos=78, limit=42, win=0x103bc30 <bss_sbrk_buffer+5653520>, face=0x349d570, string=XIL(0))
    at composite.c:928
#14 0x000000000067fad8 in composition_reseat_it
    (cmp_it=0x7fffffff8f30, charpos=40, bytepos=78, endpos=464, w=0x103bc30 <bss_sbrk_buffer+5653520>, face=0x349d570, string=XIL(0))
    at composite.c:1228
#15 0x000000000044e88f in next_element_from_buffer (it=0x7fffffff86b0) at xdisp.c:8483
#16 0x000000000044ab2a in get_next_display_element (it=0x7fffffff86b0) at xdisp.c:7026
#17 0x00000000004715db in display_line (it=0x7fffffff86b0, cursor_vpos=3) at xdisp.c:21409
#18 0x0000000000466d36 in try_window (window=XIL(0x103bc35), pos=..., flags=1) at xdisp.c:17627
#19 0x00000000004648da in redisplay_window (window=XIL(0x103bc35), just_this_one_p=false) at xdisp.c:17074
#20 0x000000000045de89 in redisplay_window_0 (window=XIL(0x103bc35)) at xdisp.c:14831
#21 0x00000000006037bc in internal_condition_case_1
    (bfun=0x45de47 <redisplay_window_0>, arg=XIL(0x103bc35), handlers=XIL(0xb3de33), hfun=0x45de0f <redisplay_window_error>) at eval.c:1356
#22 0x000000000045dde4 in redisplay_windows (window=XIL(0x103bc35)) at xdisp.c:14811
#23 0x000000000045cd16 in redisplay_internal () at xdisp.c:14300
#24 0x000000000045ada7 in redisplay () at xdisp.c:13518
#25 0x0000000000563326 in read_char (commandflag=1, map=XIL(0x142c4b3), prev_event=XIL(0), used_mouse_menu=0x7fffffffdaef, end_time=0x0)
    at keyboard.c:2480
#26 0x000000000057056f in read_key_sequence
    (keybuf=0x7fffffffdc40, bufsize=30, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9147
#27 0x00000000005607c3 in command_loop_1 () at keyboard.c:1368
#28 0x0000000000603715 in internal_condition_case (bfun=0x5603b5 <command_loop_1>, handlers=XIL(0x5250), hfun=0x55fb97 <cmd_error>)
    at eval.c:1332
#29 0x00000000005600a6 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1110
#30 0x0000000000602fed in internal_catch (tag=XIL(0xc6f0), func=0x560079 <command_loop_2>, arg=XIL(0)) at eval.c:1097
#31 0x0000000000560045 in command_loop () at keyboard.c:1089
#32 0x000000000055f76a in recursive_edit_1 () at keyboard.c:695
#33 0x000000000055f8ea in Frecursive_edit () at keyboard.c:766
#34 0x000000000055d58e in main (argc=2, argv=0x7fffffffe128) at emacs.c:1713

Lisp Backtrace:
"font-shape-gstring" (0xffff6830)
"auto-compose-chars" (0xffff6d28)
"redisplay_internal (C function)" (0x0)
(gdb) 

    >> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
    >> ftfont_shape_by_flt (matrix=<optimized out>, otf=<optimized out>, ft_face=<optimized out>, font=<optimized out>, lgstring=...)
    >> at ftfont.c:2573
    >> 2573	      g->g.to = LGLYPH_TO (LGSTRING_GLYPH (lgstring, g->g.to));

    Eli> So, is 'g' a NULL pointer or something?  Or is 'lgstring' faulty in
    Eli> some way?  IOW, what is the immediate reason for the
    Eli> segfault?

Itʼs lgstring, I think this is one of those 'nil's in lgstring

0  0x0000000000557a9d in AREF (array=XIL(0), idx=1) at lisp.h:1614
1614	  return XVECTOR (array)->contents[idx];
(gdb) up
#1  0x0000000000693602 in ftfont_shape_by_flt (lgstring=XIL(0xb64755), font=0x1308cb0 <bss_sbrk_buffer+8590480>, ft_face=0x340fef0, 
    otf=0x342c810, matrix=0x1308da8 <bss_sbrk_buffer+8590728>) at ftfont.c:2573
2573	      g->g.to = LGLYPH_TO (LGSTRING_GLYPH (lgstring, g->g.to));
(gdb) pp lgstring
[[#<font-object "-GOOG-Noto Sans Bengali-normal-normal-normal-*-19-*-*-*-*-0-iso10646-1"> 2453 8204] nil [0 0 2453 20 16 -1 17 12 0 nil] [1 1 8204 658 0 -1 1 15 4 nil] nil nil nil [5 5 0 3039 11 0 12 7 5 nil] [6 6 1606 1044 11 0 11 8 3 nil] nil]
(gdb) p g
$2 = (MFLTGlyphFT *) 0x2e631e0
(gdb) p *g
$3 = {
  g = {
    c = 2453,
    code = 20,
    from = 0,
    to = 2,
    xadv = 1024,
    yadv = 0,
    ascent = 768,
    descent = 0,
    lbearing = -64,
    rbearing = 1024,
    xoff = 0,
    yoff = 0,
    encoded = 1,
    measured = 1,
    adjusted = 0,
    internal = 0
  },
  libotf_positioning_type = 0
}

    >> (gdb) bt
    >> #0  ftfont_shape_by_fltPython Exception <class 'gdb.error'> value has been optimized out: 

    Eli> What's the story with these Python exceptions?  Looks like some
    Eli> problem in our .gdbinit?

They donʼt happen with an unoptimized build.

    Eli> The backtrace stops too soon.  Can you show more?  I'd like at the
    Eli> very least to see which sequence of characters causes the trouble.
    Eli> From the above, I can only glean that we were performing a character
    Eli> composition.

This is enough to cause the crash: ক‌

Thats #x995 followed by #x200c. Why are we trying to compose a ZWNJ?

    Eli> It could be some problem with the shaping engine: I guess versions
    Eli> after Emacs 26 are built with HarfBuzz, not m17n-flt?  If you forcibly
    Eli> use m17n-flt in a later Emacs, does it still not crash?

emacs-27 built '--without-harfbuzz' and thus with m17n-flt crashes the same way.

Robert
-- 

Previous Next

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