GNU bug report logs -
#49066
26.3; Segmentation fault on specific utf8 string
Previous Next
Reported by: "Miguel V. S. Frasson" <mvsfrasson <at> gmail.com>
Date: Wed, 16 Jun 2021 21:08:02 UTC
Severity: normal
Tags: patch
Found in version 26.3
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #20 received at 49066 <at> debbugs.gnu.org (full text, mbox):
> 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.
That'd help.
> 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));
So, is 'g' a NULL pointer or something? Or is 'lgstring' faulty in
some way? IOW, what is the immediate reason for the segfault?
> (gdb) bt
> #0 ftfont_shape_by_fltPython Exception <class 'gdb.error'> value has been optimized out:
What's the story with these Python exceptions? Looks like some
problem in our .gdbinit?
> (matrix=<optimized out>, otf=<optimized out>, ft_face=<optimized out>, font=<optimized out>, lgstring=)
> at ftfont.c:2573
> #1 ftfont_shapePython Exception <class 'gdb.error'> value has been optimized out:
> (lgstring=, lgstring <at> entry=XIL(0xaa2755)) at ftfont.c:2615
> #2 0x00000000005d97f5 in xftfont_shape (lgstring=XIL(0xaa2755)) at xftfont.c:670
> #3 0x000000000057fc2a in Ffont_shape_gstringPython Exception <class 'gdb.error'> value has been optimized out:
> (gstring=) at font.c:4427
> #4 0x000000000056fede in funcall_subr (subr=0x97fac0 <Sfont_shape_gstring>, numargs=numargs <at> entry=1, args=args <at> entry=0x7fffffff59a0)
> at eval.c:2844
> #5 0x000000000056ecff in Ffuncall (nargs=<optimized out>, args=args <at> entry=0x7fffffff5998) at lisp.h:600
The backtrace stops too soon. Can you show more? I'd like at the
very least to see which sequence of characters causes the trouble.
From the above, I can only glean that we were performing a character
composition.
It could be some problem with the shaping engine: I guess versions
after Emacs 26 are built with HarfBuzz, not m17n-flt? If you forcibly
use m17n-flt in a later Emacs, does it still not crash?
Thanks.
This bug report was last modified 3 years and 306 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.