GNU bug report logs - #48732
28.0.50; lisp_string_width segfaults on startup under macOS

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 48732 in the body.
You can then email your comments to 48732 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: Naofumi Yasufuku <naofumi <at> yasufuku.dev>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; lisp_string_width segfaults on startup under macOS
Date: Sun, 30 May 2021 04:28:11 +0900

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

After changes for auto-composition aware string-width (*),
emacs segfaults frequently on startup under macOS.

gdb 'bt full’ is attached:
  emacs_crash-lisp_string_width-gdb_bt_full.txt
  emacs_crash-lisp_string_width-macOS_report.txt

On my machine, crash occurrence frequency can be increased with
attached init.el.  Unfortunately, I cannot reproduce the crash with
`--enable-checking='yes,glyphs' --enable-check-lisp-object-type`
configure options.

Sometimes emacs starts without crash, but font setting is corrupted
like the attached screenshot: after-lisp_string_width-autocmp.png

Regards,
—Naofumi

(*)
--------------------------------------------------------------------------------
commit 85da7b57bc204c4cc6953156c1a9a4dc6e875541
Author: Eli Zaretskii <eliz <at> gnu.org>
Date:   Wed May 26 20:08:47 2021 +0300

    Make 'string-width' auto-composition aware

    * src/composite.c (find_automatic_composition): Now extern.
    (char_composable_p): Don't assume 'unicode-category-table' is
    always available.
    * src/composite.h (find_automatic_composition): Add prototype.
    * src/character.c (lisp_string_width): Support automatic
    compositions; call 'find_automatic_composition' when
    'auto-composition-mode' is ON.
--------------------------------------------------------------------------------

(gdb) bt
#0  0x000000010028e955 in SYMBOL_NAME (sym=0x104621ba0) at ./lisp.h:2208
#1  0x000000010028e42d in font_style_to_value (prop=FONT_WIDTH_INDEX,
    val=0x104621ba0, noerror=true) at font.c:366
#2  0x00000001002976de in font_select_entity (f=0x10433f230,
    entities=0x1048cb913, attrs=0x103778800, pixel_size=12, c=-1)
    at font.c:3159
#3  0x00000001002971b9 in font_find_for_lface (f=0x10433f230,
    attrs=0x103778800, spec=0x10422c7ed, c=-1) at font.c:3302
#4  0x000000010033905e in fontset_find_font (fontset=0x104419835, c=1603,
    face=0x103778800, charset_id=-1, fallback=false) at fontset.c:660
#5  0x0000000100331c94 in fontset_font (fontset=0x10493a08d, c=1603,
    face=0x103778800, id=-1) at fontset.c:782
#6  0x000000010033228d in font_for_char (face=0x103778800, c=1603, pos=308,
    object=0x1033e79c4) at fontset.c:1063
#7  0x0000000100299d4f in font_range (pos=309, pos_byte=336,
    limit=0x7ffeefbf1310, w=0x104342e20, face=0x103778800, string=0x1033e79c4)
    at font.c:3883
#8  0x0000000100324fce in autocmp_chars (rule=0x105f2311d, charpos=308,
    bytepos=334, limit=312, win=0x104342e20, face=0x0, string=0x1033e79c4,
    direction=0x0) at composite.c:923
#9  0x0000000100325f1d in find_automatic_composition (pos=308, limit=308,
    start=0x7ffeefbf15a8, end=0x7ffeefbf15a0, gstring=0x7ffeefbf15b8,
    string=0x1033e79c4) at composite.c:1612
#10 0x00000001001248c8 in lisp_string_width (string=0x1033e79c4, from=0,
    to=479, precision=-1, nchars=0x7ffeefbf1a28, nbytes=0x7ffeefbf1a20)
    at character.c:375
#11 0x00000001002514db in styled_format (nargs=2, args=0x7ffeefbf74c0,
    message=false) at editfns.c:3392
#12 0x000000010024f48f in Fformat (nargs=2, args=0x7ffeefbf74c0)
    at editfns.c:3061
#13 0x000000010026b23b in call3 (fn=0x100420bf5, arg1=0x1000000000,
    arg2=0x7ffeefbf73f0, arg3=0x10026ec04 <xcdr_addr+20>) at eval.c:2912
#14 0x00000037c0001000 in ?? ()
#15 0x0000003700007170 in ?? ()
#16 0x00007fff80898338 in ?? ()
#17 0x0001003700000037 in ?? ()
#18 0x00007ffe0000005d in ?? ()
#19 0x00007ffeefbf751c in ?? ()
#20 0x0000000000007170 in ?? ()
#21 0x0000000000000000 in ?? ()
(gdb) 
--------------------------------------------------------------------------------

[emacs_crash-lisp_string_width-gdb_bt_full.txt (text/plain, attachment)]

[emacs_crash-lisp_string_width-macOS_report.txt (text/plain, attachment)]

[init.el (application/octet-stream, attachment)]

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

--------------------------------------------------------------------------------

In GNU Emacs 28.0.50 (build 4, x86_64-apple-darwin20.5.0, NS appkit-2022.50 Version 11.4 (Build 20F71))
of 2021-05-30 built on hyperion.local
Repository revision: 4d4c73da5a0aa4233b1dcdcf7db068fc79db6513
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.4

Configured using:
'configure 'CFLAGS=-O0 -g3''

Configured features:
ACL DBUS GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
KQUEUE NS PDUMPER PNG RSVG THREADS TIFF TOOLKIT_SCROLL_BARS XIM ZLIB

Important settings:
  value of $LANG: ja_JP.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/Users/naofumi/.emacs.d/elpa/transient-20210525.1141/transient hides /Users/naofumi/_git/git.sv.gnu.org/emacs/lisp/transient

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs text-property-search mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils ccc tramp
tramp-loaddefs trampver tramp-integration files-x tramp-compat shell
pcomplete comint ansi-color ring parse-time iso8601 time-date ls-lisp
format-spec advice edmacro kmacro slime-autoloads info package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib japan-util iso-transl tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
kqueue cocoa ns lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 102680 5259)
(symbols 48 11172 1)
(strings 32 36392 1490)
(string-bytes 1 1368236)
(vectors 16 21653)
(vector-slots 8 343327 9248)
(floats 8 36 13)
(intervals 56 340 0)
(buffers 992 11))

--------------------------------------------------------------------------------

[after-lisp_string_width-autocmp.png (image/png, inline)]

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

[before-lisp_string_width-autocmp.png (image/png, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Naofumi Yasufuku <naofumi <at> yasufuku.dev>
Cc: 48732 <at> debbugs.gnu.org
Subject: Re: bug#48732: 28.0.50;
 lisp_string_width segfaults on startup under macOS
Date: Sat, 29 May 2021 23:32:42 +0300

> From: Naofumi Yasufuku <naofumi <at> yasufuku.dev>
> Date: Sun, 30 May 2021 04:28:11 +0900
> 
> After changes for auto-composition aware string-width (*),
> emacs segfaults frequently on startup under macOS.
> 
> gdb 'bt full’ is attached:
>   emacs_crash-lisp_string_width-gdb_bt_full.txt
>   emacs_crash-lisp_string_width-macOS_report.txt
> 
> On my machine, crash occurrence frequency can be increased with
> attached init.el.  Unfortunately, I cannot reproduce the crash with
> `--enable-checking='yes,glyphs' --enable-check-lisp-object-type`
> configure options.
> 
> Sometimes emacs starts without crash, but font setting is corrupted
> like the attached screenshot: after-lisp_string_width-autocmp.png

I cannot reproduce using your init.el.

> (gdb) p sym
> $1 = (Lisp_Object) 0x104621ba0
> (gdb) p XSYMBOL(sym)
> [New Thread 0x1b1f of process 79812]
> [New Thread 0x2a03 of process 79812]
> $2 = (struct Lisp_Symbol *) 0x204e4a730
> (gdb) p XSYMBOL(sym)->u
> Cannot access memory at address 0x204e4a730
> (gdb) p XSYMBOL(sym)->u.s
> Cannot access memory at address 0x204e4a730
> (gdb) p XSYMBOL(sym)->u.s.name
> Cannot access memory at address 0x204e4a738

So it's some kind of invalid "symbol".

> (gdb) up
> #2  0x00000001002976de in font_select_entity (f=0x10433f230,
>     entities=0x1048cb913, attrs=0x103778800, pixel_size=12, c=-1)
>     at font.c:3159
> 3159	    FONT_SET_STYLE (prefer, FONT_WIDTH_INDEX, attrs[LFACE_SWIDTH_INDEX]);
> (gdb) up
> #3  0x00000001002971b9 in font_find_for_lface (f=0x10433f230,
>     attrs=0x103778800, spec=0x10422c7ed, c=-1) at font.c:3302
> 3302			      val = font_select_entity (f, entities,

What is 'spec' in this frame?

  (gdb) pp spec

> (gdb) up
> #4  0x000000010033905e in fontset_find_font (fontset=0x104419835, c=1603,
>     face=0x103778800, charset_id=-1, fallback=false) at fontset.c:660
> 660		  font_entity = font_find_for_lface (f, face->lface,

What is 'fontset' in this frame?

> #8  0x0000000100324fce in autocmp_chars (rule=0x105f2311d, charpos=308,
>     bytepos=334, limit=312, win=0x104342e20, face=0x0, string=0x1033e79c4,
>     direction=0x0) at composite.c:923
> 923	      font_object = font_range (charpos, bytepos, &to, win, face, string);
> (gdb) up
> #9  0x0000000100325f1d in find_automatic_composition (pos=308, limit=308,
>     start=0x7ffeefbf15a8, end=0x7ffeefbf15a0, gstring=0x7ffeefbf15b8,
>     string=0x1033e79c4) at composite.c:1612
> 1612			  *gstring = autocmp_chars (elt, check.pos, check.pos_byte,
> (gdb) up
> #10 0x00000001001248c8 in lisp_string_width (string=0x1033e79c4, from=0,
>     to=479, precision=-1, nchars=0x7ffeefbf1a28, nbytes=0x7ffeefbf1a20)
>     at character.c:375
> 375		       && find_automatic_composition (i, -1, &ignore, &end, &val, string)

This seems to indicate Emacs is asking string-width to compute width
of a string that has 479 characters?  How come we have such a long
string here?

  (gdb) pp string

> (gdb) up
> #11 0x00000001002514db in styled_format (nargs=2, args=0x7ffeefbf74c0,
>     message=false) at editfns.c:3392
> 3392			  width = lisp_string_width (arg, 0, nchars_string, prec,
> (gdb) up
> #12 0x000000010024f48f in Fformat (nargs=2, args=0x7ffeefbf74c0)
>     at editfns.c:3061
> 3061	  return styled_format (nargs, args, false);

What are the arguments to 'format' here?

  (gdb) pp args[0]
  (gdb) pp args[1]

> (gdb) up
> #13 0x000000010026b23b in call3 (fn=0x100420bf5, arg1=0x1000000000,
>     arg2=0x7ffeefbf73f0, arg3=0x10026ec04 <xcdr_addr+20>) at eval.c:2912
> 2912	{

What function is being called here, and with what arguments?

  (gdb) pp fn
  (gdb) pp arg1
  (gdb) pp arg2
  (gdb) pp arg3

The command 'pp' is defined in src/.gdbinit, you may need to source
that file before you could use the command.

Thanks.

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

From: Naofumi Yasufuku <naofumi <at> yasufuku.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48732 <at> debbugs.gnu.org
Subject: Re: bug#48732: 28.0.50; lisp_string_width segfaults on startup under
 macOS
Date: Sun, 30 May 2021 07:10:30 +0900

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

Hi Eli,

I succeeded in getting more details by gdb ‘pp’ command.
`format’ call, leads to lisp_string_width crash, seems `tramp-password-prompt-regexp'.

Please look at the attached log and screenshot:
  emacs_crash-lisp_string_width-gdb_bt_full-with-pp.txt.bz2
  emacs_crash-lisp_string_width-gdb_bt_full-with-pp.png

It seems that this segfault depends on some delicate matter of
startup initialization timing.

This crash couldn’t be reproduced with full ${top_builddir}/src/.gdbinit settings,
so I copied ‘pp’ command definition to ${top_builddir}/.gdbinit then invoked
'gdb ${top_builddir}/src/emacs' like this:

```
[naofumi <at> hyperion emacs (master)]% pwd
/Users/naofumi/_git/git.sv.gnu.org/emacs
[naofumi <at> hyperion emacs (master)]% 
[naofumi <at> hyperion emacs (master)]% cat ./.gdbinit
# Print out s-expressions
define pp
  set $tmp = $arg0
  set $output_debug = print_output_debug_flag
  set print_output_debug_flag = 0
  call safe_debug_print ($tmp)
  set print_output_debug_flag = $output_debug
end
document pp
Print the argument as an emacs s-expression
Works only when an inferior emacs is executing.
end
[naofumi <at> hyperion emacs (master)]% 
[naofumi <at> hyperion emacs (master)]% 
[naofumi <at> hyperion emacs (master)]% gdb ./src/emacs
GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin20.3.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./src/emacs...
(gdb) r
Starting program: /Users/naofumi/_git/git.sv.gnu.org/emacs/src/emacs 
[New Thread 0x1a03 of process 82588]
[New Thread 0x2303 of process 82588]
warning: unhandled dyld version (17)
[New Thread 0x1c03 of process 82588]
[New Thread 0x2003 of process 82588]
[New Thread 0x2103 of process 82588]
[New Thread 0x2203 of process 82588]
[New Thread 0x2407 of process 82588]
[New Thread 0x1a17 of process 82588]
[New Thread 0x1d13 of process 82588]

Thread 2 received signal SIGSEGV, Segmentation fault.
0x000000010028e955 in SYMBOL_NAME (sym=0x1700000018) at ./lisp.h:2208
2208	  return XSYMBOL (sym)->u.s.name;
(gdb) bt full
#0  0x000000010028e955 in SYMBOL_NAME (sym=0x1700000018) at ./lisp.h:2208
No locals.
#1  0x000000010028e42d in font_style_to_value (prop=FONT_WEIGHT_INDEX, 
    val=0x1700000018, noerror=true) at font.c:366
        i = 10
        j = 4
        s = 0x50000000c <error: Cannot access memory at address 0x50000000c>
        elt = 0x10433298d
        table = 0x1056f8b5d
        len = 10
```

[emacs_crash-lisp_string_width-gdb_bt_full-with-pp.txt.bz2 (application/x-bzip2, attachment)]

[emacs_crash-lisp_string_width-gdb_bt_full-with-pp.png (image/png, inline)]

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

> 2021/05/30 5:32、Eli Zaretskii <eliz <at> gnu.org>のメール:
> 
>> From: Naofumi Yasufuku <naofumi <at> yasufuku.dev>
>> Date: Sun, 30 May 2021 04:28:11 +0900
>> 
>> After changes for auto-composition aware string-width (*),
>> emacs segfaults frequently on startup under macOS.
>> 
>> gdb 'bt full’ is attached:
>>  emacs_crash-lisp_string_width-gdb_bt_full.txt
>>  emacs_crash-lisp_string_width-macOS_report.txt
>> 
>> On my machine, crash occurrence frequency can be increased with
>> attached init.el.  Unfortunately, I cannot reproduce the crash with
>> `--enable-checking='yes,glyphs' --enable-check-lisp-object-type`
>> configure options.
>> 
>> Sometimes emacs starts without crash, but font setting is corrupted
>> like the attached screenshot: after-lisp_string_width-autocmp.png
> 
> I cannot reproduce using your init.el.
> 
>> (gdb) p sym
>> $1 = (Lisp_Object) 0x104621ba0
>> (gdb) p XSYMBOL(sym)
>> [New Thread 0x1b1f of process 79812]
>> [New Thread 0x2a03 of process 79812]
>> $2 = (struct Lisp_Symbol *) 0x204e4a730
>> (gdb) p XSYMBOL(sym)->u
>> Cannot access memory at address 0x204e4a730
>> (gdb) p XSYMBOL(sym)->u.s
>> Cannot access memory at address 0x204e4a730
>> (gdb) p XSYMBOL(sym)->u.s.name
>> Cannot access memory at address 0x204e4a738
> 
> So it's some kind of invalid "symbol".
> 
>> (gdb) up
>> #2  0x00000001002976de in font_select_entity (f=0x10433f230,
>>    entities=0x1048cb913, attrs=0x103778800, pixel_size=12, c=-1)
>>    at font.c:3159
>> 3159	    FONT_SET_STYLE (prefer, FONT_WIDTH_INDEX, attrs[LFACE_SWIDTH_INDEX]);
>> (gdb) up
>> #3  0x00000001002971b9 in font_find_for_lface (f=0x10433f230,
>>    attrs=0x103778800, spec=0x10422c7ed, c=-1) at font.c:3302
>> 3302			      val = font_select_entity (f, entities,
> 
> What is 'spec' in this frame?
> 
>  (gdb) pp spec
> 
>> (gdb) up
>> #4  0x000000010033905e in fontset_find_font (fontset=0x104419835, c=1603,
>>    face=0x103778800, charset_id=-1, fallback=false) at fontset.c:660
>> 660		  font_entity = font_find_for_lface (f, face->lface,
> 
> What is 'fontset' in this frame?
> 
>> #8  0x0000000100324fce in autocmp_chars (rule=0x105f2311d, charpos=308,
>>    bytepos=334, limit=312, win=0x104342e20, face=0x0, string=0x1033e79c4,
>>    direction=0x0) at composite.c:923
>> 923	      font_object = font_range (charpos, bytepos, &to, win, face, string);
>> (gdb) up
>> #9  0x0000000100325f1d in find_automatic_composition (pos=308, limit=308,
>>    start=0x7ffeefbf15a8, end=0x7ffeefbf15a0, gstring=0x7ffeefbf15b8,
>>    string=0x1033e79c4) at composite.c:1612
>> 1612			  *gstring = autocmp_chars (elt, check.pos, check.pos_byte,
>> (gdb) up
>> #10 0x00000001001248c8 in lisp_string_width (string=0x1033e79c4, from=0,
>>    to=479, precision=-1, nchars=0x7ffeefbf1a28, nbytes=0x7ffeefbf1a20)
>>    at character.c:375
>> 375		       && find_automatic_composition (i, -1, &ignore, &end, &val, string)
> 
> This seems to indicate Emacs is asking string-width to compute width
> of a string that has 479 characters?  How come we have such a long
> string here?
> 
>  (gdb) pp string
> 
>> (gdb) up
>> #11 0x00000001002514db in styled_format (nargs=2, args=0x7ffeefbf74c0,
>>    message=false) at editfns.c:3392
>> 3392			  width = lisp_string_width (arg, 0, nchars_string, prec,
>> (gdb) up
>> #12 0x000000010024f48f in Fformat (nargs=2, args=0x7ffeefbf74c0)
>>    at editfns.c:3061
>> 3061	  return styled_format (nargs, args, false);
> 
> What are the arguments to 'format' here?
> 
>  (gdb) pp args[0]
>  (gdb) pp args[1]
> 
>> (gdb) up
>> #13 0x000000010026b23b in call3 (fn=0x100420bf5, arg1=0x1000000000,
>>    arg2=0x7ffeefbf73f0, arg3=0x10026ec04 <xcdr_addr+20>) at eval.c:2912
>> 2912	{
> 
> What function is being called here, and with what arguments?
> 
>  (gdb) pp fn
>  (gdb) pp arg1
>  (gdb) pp arg2
>  (gdb) pp arg3
> 
> The command 'pp' is defined in src/.gdbinit, you may need to source
> that file before you could use the command.
> 
> Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Naofumi Yasufuku <naofumi <at> yasufuku.dev>
Cc: 48732 <at> debbugs.gnu.org
Subject: Re: bug#48732: 28.0.50; lisp_string_width segfaults on startup under
 macOS
Date: Sun, 30 May 2021 11:38:27 +0300

> From: Naofumi Yasufuku <naofumi <at> yasufuku.dev>
> Date: Sun, 30 May 2021 07:10:30 +0900
> Cc: 48732 <at> debbugs.gnu.org
> 
> I succeeded in getting more details by gdb ‘pp’ command.
> `format’ call, leads to lisp_string_width crash, seems `tramp-password-prompt-regexp'.
> 
> Please look at the attached log and screenshot:
>   emacs_crash-lisp_string_width-gdb_bt_full-with-pp.txt.bz2
>   emacs_crash-lisp_string_width-gdb_bt_full-with-pp.png
> 
> It seems that this segfault depends on some delicate matter of
> startup initialization timing.

Maybe.  At least the user init file is processed during startup after
the window-system was fully initialized.  The fontset you show in your
crashed session also looks fine to me.  So I cannot explain why trying
to find font for an Arabic character could crash for you.

Therefore, I went ahead and disabled accounting for automatic
character compositions in 'format' and 'format-message'.  Only
'string-width' tries to account for that.  Please see if that solves
your problem.

> This crash couldn’t be reproduced with full ${top_builddir}/src/.gdbinit settings,
> so I copied ‘pp’ command definition to ${top_builddir}/.gdbinit then invoked
> 'gdb ${top_builddir}/src/emacs' like this:

This in itself is very strange, and probably indicates that there's
some memory-related problem somewhere.  If the change I installed
solves your problem, I will try looking for such a problem.

Thanks.

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

From: Naofumi Yasufuku <naofumi <at> yasufuku.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48732 <at> debbugs.gnu.org
Subject: Re: bug#48732: 28.0.50; lisp_string_width segfaults on startup under
 macOS
Date: Sun, 30 May 2021 18:06:33 +0900

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

Hi Eli,

> 2021/05/30 17:38、Eli Zaretskii <eliz <at> gnu.org>のメール:
> 
> Maybe.  At least the user init file is processed during startup after
> the window-system was fully initialized.  The fontset you show in your
> crashed session also looks fine to me.  So I cannot explain why trying
> to find font for an Arabic character could crash for you.
> 
> Therefore, I went ahead and disabled accounting for automatic
> character compositions in 'format' and 'format-message'.  Only
> 'string-width' tries to account for that.  Please see if that solves
> your problem.
> 

No problem. I’ll try it.

>> This crash couldn’t be reproduced with full ${top_builddir}/src/.gdbinit settings,
>> so I copied ‘pp’ command definition to ${top_builddir}/.gdbinit then invoked
>> 'gdb ${top_builddir}/src/emacs' like this:
> 
> This in itself is very strange, and probably indicates that there's
> some memory-related problem somewhere.  If the change I installed
> solves your problem, I will try looking for such a problem.
> 

Yes, very strange. It seems memory or cache related.

I have tried to get simple printf logs of crashed `lface’  Lisp_Object access via
lisp_gtring_width()/find_automatic_composition() and free_realized_face().

According to the attached logs, find_automatic_composition() could attempt to access
to deallocated `lface’ objects on startup under macOS.

It could be macOS-specific because I have not seen such segfault under linux.


## Patch for realize_face, free_realized_face printf logs

attachment:
0001-free_realized_face-printf-logs-for-lisp_string_width.patch
init.el

Except for this printf patch, there is no difference of execution environment
described in previous email.

> 
> It seems that this segfault depends on some delicate matter of
> startup initialization timing.
> 
> This crash couldn’t be reproduced with full ${top_builddir}/src/.gdbinit settings,
> so I copied ‘pp’ command definition to ${top_builddir}/.gdbinit then invoked
> 'gdb ${top_builddir}/src/emacs' like this:
> 
> ```
> [naofumi <at> hyperion emacs (master)]% pwd
> /Users/naofumi/_git/git.sv.gnu.org/emacs
> [naofumi <at> hyperion emacs (master)]% 
> [naofumi <at> hyperion emacs (master)]% cat ./.gdbinit
> # Print out s-expressions
> define pp
>  set $tmp = $arg0
>  set $output_debug = print_output_debug_flag
>  set print_output_debug_flag = 0
>  call safe_debug_print ($tmp)
>  set print_output_debug_flag = $output_debug
> end
> document pp
> Print the argument as an emacs s-expression
> Works only when an inferior emacs is executing.
> end
> [naofumi <at> hyperion emacs (master)]% 
> [naofumi <at> hyperion emacs (master)]% 
> [naofumi <at> hyperion emacs (master)]% gdb ./src/emacs


## Case A) lisp_string_width segfault occurrs

attachment:
00_SEGFAULT-free_realized_face-gdb-grep-0x1032af4a0.txt
00_SEGFAULT-free_realized_face-gdb.txt.bz2
01_SEGFAULT-free_realized_face-gdb-grep-0x103435210.txt
01_SEGFAULT-free_realized_face-gdb.txt.bz2
--------------------------------------------------------------------------------------------------------------
realize_gui_face: make_realized_face: face=0x1032af4a0: face->lface=0x1032af4a0
realize_face: realize_gui_face: face=0x1032af4a0: face->lface=0x1032af4a0
free_realized_face: frame f=0x104197430: face=0x1032af4a0
xfree: block=0x1032af4a0
realize_gui_face: make_realized_face: face=0x1032af4a0: face->lface=0x1032af4a0
realize_face: realize_gui_face: face=0x1032af4a0: face->lface=0x1032af4a0
free_realized_face: frame f=0x104197430: face=0x1032af4a0
xfree: block=0x1032af4a0
realize_gui_face: make_realized_face: face=0x1032af4a0: face->lface=0x1032af4a0
realize_face: realize_gui_face: face=0x1032af4a0: face->lface=0x1032af4a0
font_range: frame f=0x104197430: face_id=0: face=0x1032af4a0
fontset_find_font: frame f=0x104197430: XFRAME(FONTSET_FRAME(fontset)=0x104197430: XFRAME(selected_frame)=0x104197430: face=0x1032af4a0
fontset_find_font: frame f=0x104197430: XFRAME(FONTSET_FRAME(fontset)=0x104197430: XFRAME(selected_frame)=0x104197430: face=0x1032af4a0
free_realized_face: frame f=0x104197430: face=0x1032af4a0
xfree: block=0x1032af4a0
font_select_entity: frame f=0x104197430: attrs=0x1032af4a0

Thread 2 received signal SIGSEGV, Segmentation fault.
0x0000000100291d05 in SYMBOL_NAME (sym=0x10421bc28) at ./lisp.h:2208
2208	  return XSYMBOL (sym)->u.s.name;
(gdb) bt
#0  0x0000000100291d05 in SYMBOL_NAME (sym=0x10421bc28) at ./lisp.h:2208
#1  0x00000001002917dd in font_style_to_value (prop=FONT_WEIGHT_INDEX, 
    val=0x10421bc28, noerror=true) at font.c:366
#2  0x000000010029a9c3 in font_select_entity (f=0x104197430, 
    entities=0x1038add13, attrs=0x1032af4a0, pixel_size=12, c=-1)
    at font.c:3158
#3  0x000000010029a569 in font_find_for_lface (f=0x104197430, 
    attrs=0x1032af4a0, spec=0x104909ded, c=-1) at font.c:3305
#4  0x000000010033c504 in fontset_find_font (fontset=0x104a05545, c=1603, 
    face=0x1032af4a0, charset_id=-1, fallback=false) at fontset.c:663
#5  0x00000001003350a4 in fontset_font (fontset=0x10421ae8d, c=1603, 
    face=0x1032af4a0, id=-1) at fontset.c:785
#6  0x000000010033569d in font_for_char (face=0x1032af4a0, c=1603, pos=308, 
    object=0x10317e5c4) at fontset.c:1066
#7  0x000000010029d15a in font_range (pos=309, pos_byte=336, 
    limit=0x7ffeefbf1310, w=0x104175c20, face=0x1032af4a0, string=0x10317e5c4)
    at font.c:3887
#8  0x00000001003283de in autocmp_chars (rule=0x105f2337d, charpos=308, 
    bytepos=334, limit=312, win=0x104175c20, face=0x0, string=0x10317e5c4, 
    direction=0x0) at composite.c:923
#9  0x000000010032932d in find_automatic_composition (pos=308, limit=308, 
    start=0x7ffeefbf15a8, end=0x7ffeefbf15a0, gstring=0x7ffeefbf15b8, 
    string=0x10317e5c4) at composite.c:1612
#10 0x0000000100127468 in lisp_string_width (string=0x10317e5c4, from=0, 
    to=479, precision=-1, nchars=0x7ffeefbf1a28, nbytes=0x7ffeefbf1a20)
    at character.c:375
#11 0x000000010025488b in styled_format (nargs=2, args=0x7ffeefbf74c0, 
    message=false) at editfns.c:3392
#12 0x000000010025283f in Fformat (nargs=2, args=0x7ffeefbf74c0)
    at editfns.c:3061
#13 0x000000010026e5eb in call3 (fn=0x100424ddd, arg1=0x1000000000, 
    arg2=0x7ffeefbf73f0, arg3=0x100271fb4 <xcdr_addr+20>) at eval.c:2912
#14 0x7830003700000806 in ?? ()
#15 0x0000000000000000 in ?? ()
(gdb) pp sym
[New Thread 0x1d0b of process 7056]
#<INVALID_LISP_OBJECT 0x10421bc28>
(gdb) up
#1  0x00000001002917dd in font_style_to_value (prop=FONT_WEIGHT_INDEX, 
    val=0x10421bc28, noerror=true) at font.c:366
366	      s = SSDATA (SYMBOL_NAME (val));
(gdb) up
#2  0x000000010029a9c3 in font_select_entity (f=0x104197430, 
    entities=0x1038add13, attrs=0x1032af4a0, pixel_size=12, c=-1)
    at font.c:3158
3158	    FONT_SET_STYLE (prefer, FONT_WEIGHT_INDEX, attrs[LFACE_WEIGHT_INDEX]);
(gdb) up
#3  0x000000010029a569 in font_find_for_lface (f=0x104197430, 
    attrs=0x1032af4a0, spec=0x104909ded, c=-1) at font.c:3305
3305			      val = font_select_entity (f, entities,
(gdb) up
#4  0x000000010033c504 in fontset_find_font (fontset=0x104a05545, c=1603, 
    face=0x1032af4a0, charset_id=-1, fallback=false) at fontset.c:663
663		  font_entity = font_find_for_lface (f, face->lface,
(gdb) pp face->lface[0]
nil
(gdb) pp face->lface[1]
#<INVALID_LISP_OBJECT 0x10421bc18>
(gdb) pp face->lface[2]
0
(gdb) pp face->lface[3]
#<INVALID_LISP_OBJECT 0xffffffffffffffff>
(gdb) pp face->lface[4]
nil
(gdb) pp face->lface[5]
#<INVALID_LISP_OBJECT 0x10421bc28>
(gdb) pp face->lface[6]
0
(gdb) pp face->lface[7]
#<INVALID_LISP_OBJECT 0xffffffffffffffff>
(gdb) pp face->lface
$1 = {0x0, 0x10421bc18, 0x2, 0xffffffffffffffff, 0x0, 0x10421bc28, 0x2, 
  0xffffffffffffffff, 0x0, 0x10421bc38, 0x2, 0xffffffffffffffff, 0x0, 
  0x10421bc48, 0x2, 0xffffffffffffffff, 0x0, 0x10421bc58, 0x2, 
  0xffffffffffffffff}
(gdb) q

--------------------------------------------------------------------------------------------------------------


##  Case B) No lisp_string_width segfault

attachment:
10_NO-SEGFAULT-free_realized_face-gdb-grep-0x1032cb260.txt
10_NO-SEGFAULT-free_realized_face-gdb.txt.bz2
11_NO-SEGFAULT-free_realized_face-gdb-grep-0x1031a5880.txt
11_NO-SEGFAULT-free_realized_face-gdb.txt.bz2
--------------------------------------------------------------------------------------------------------------
realize_gui_face: make_realized_face: face=0x1032cb260: face->lface=0x1032cb260
realize_face: realize_gui_face: face=0x1032cb260: face->lface=0x1032cb260
free_realized_face: frame f=0x108088e30: face=0x1032cb260
xfree: block=0x1032cb260
realize_gui_face: make_realized_face: face=0x1032cb260: face->lface=0x1032cb260
realize_face: realize_gui_face: face=0x1032cb260: face->lface=0x1032cb260
font_range: frame f=0x108088e30: face_id=0: face=0x1032cb260
fontset_find_font: frame f=0x108088e30: XFRAME(FONTSET_FRAME(fontset)=0x108088e30: XFRAME(selected_frame)=0x108088e30: face=0x1032cb260
fontset_find_font: frame f=0x108088e30: XFRAME(FONTSET_FRAME(fontset)=0x108088e30: XFRAME(selected_frame)=0x108088e30: face=0x1032cb260
free_realized_face: frame f=0x108088e30: face=0x1032cb260
xfree: block=0x1032cb260
realize_gui_face: make_realized_face: face=0x1032cb260: face->lface=0x1032cb260
realize_face: realize_gui_face: face=0x1032cb260: face->lface=0x1032cb260
font_select_entity: frame f=0x108088e30: attrs=0x1032cb260

--------------------------------------------------------------------------------------------------------------


Regards,
—Naofumi

[0001-free_realized_face-printf-logs-for-lisp_string_width.patch (application/octet-stream, attachment)]

[init.el (application/octet-stream, attachment)]

[00_SEGFAULT-free_realized_face-gdb-grep-0x1032af4a0.txt (text/plain, attachment)]

[00_SEGFAULT-free_realized_face-gdb.txt.bz2 (application/x-bzip2, attachment)]

[01_SEGFAULT-free_realized_face-gdb-grep-0x103435210.txt (text/plain, attachment)]

[01_SEGFAULT-free_realized_face-gdb.txt.bz2 (application/x-bzip2, attachment)]

[10_NO-SEGFAULT-free_realized_face-gdb-grep-0x1032cb260.txt (text/plain, attachment)]

[10_NO-SEGFAULT-free_realized_face-gdb.txt.bz2 (application/x-bzip2, attachment)]

[11_NO-SEGFAULT-free_realized_face-gdb-grep-0x1031a5880.txt (text/plain, attachment)]

[11_NO-SEGFAULT-free_realized_face-gdb.txt.bz2 (application/x-bzip2, attachment)]

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

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

From: Naofumi Yasufuku <naofumi <at> yasufuku.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48732 <at> debbugs.gnu.org
Subject: Re: bug#48732: 28.0.50; lisp_string_width segfaults on startup under
 macOS
Date: Mon, 31 May 2021 23:27:02 +0900

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

> On May 30, 2021, at 18:06, Naofumi Yasufuku <naofumi <at> yasufuku.dev> wrote:
> 
>> 2021/05/30 17:38、Eli Zaretskii <eliz <at> gnu.org>のメール:
>> 
>> Maybe.  At least the user init file is processed during startup after
>> the window-system was fully initialized.  The fontset you show in your
>> crashed session also looks fine to me.  So I cannot explain why trying
>> to find font for an Arabic character could crash for you.
>> 
>> Therefore, I went ahead and disabled accounting for automatic
>> character compositions in 'format' and 'format-message'.  Only
>> 'string-width' tries to account for that.  Please see if that solves
>> your problem.
>> 
> 
> No problem. I’ll try it.

------------------------------------------------------------------------
commit 23ad0f0c5adbeda9a0bd346138e2950cb5e5a136
Author: Eli Zaretskii <eliz <at> gnu.org>
Date:   Sun May 30 11:16:59 2021 +0300

    Don't account for character compositions in 'format' and friends
    
    'lisp_string_width' is called from 'format' and 'format-message',
    which can be called both very early into Emacs initialization and in
    other contexts where using the font backend is impossible or
    undesirable.  So this commit changes 'lisp_string_width' to try
    accounting for automatic compositions only when explicitly requested,
    and only 'string-width' does that; 'format' and 'format-message'
    don't.
    * src/character.c (lisp_string_width): Accept an additional
    argument AUTO_COMP; attempt accounting for auto-compositions only
    if that argument is non-zero.  (Bug#48732)
    * src/editfns.c (styled_format):
    * src/character.c (Fstring_width): Callers of 'lisp_string_width'
    adjusted.
------------------------------------------------------------------------

This workaround works fine.  I think this issue can be closed.

Access to unrealized 'face->lface' Lisp_Object is not seen anymore
on startup, and no segfault happens with both simple reproducing
'tramp-syntax’ init.el and my daily-use more complicated init.el.

I comfirmed it on two intel macs which this segfault was observed:
  - MacBook running the latest macOS 11.4
  - Mac mini running macOS 10.14

At the same time, font corruption issue with some themes is also disappeared
as Pankaj said on emacs-devel list.
(After autocmp string-width commits, I had seen the font corruption
issue frequently with doom-tomorrow-night of doom-themes package.)

> From: Pankaj Jangid <pankaj <at> codeisgreat.org>
> Subject: Re: This init file is crashing emacs on macos 11.4
> Date: Sun, 30 May 2021 15:34:36 +0530
> Cc: larsi <at> gnus.org, emacs-devel <at> gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> >>> The attached init file is crashing emacs on macos 11.4.
> >> >>
> >> >> Could this be the same bug as bug#48732?
> >> >
> >> > Yes. This could be. Because Naofumi also says that the fonts settings
> >> > are corrupted when it doesn’t crash. I observe the same behavior. But I
> >> > get the corrupted font only when using modus-operandi theme.
> >> >
> >> 
> >> And this could also be related. bug#48714.
> >
> > Does it still happen with the current master?
> 
> Both the issues disappeared for me. Nice. :-)


Regards,
--Naofumi


------------------------------------------------------------------------

## Verification with printf debug logs

I tried 10 times gdb session, and no segfault happens.

attachment:
Bug48732-lisp_string_width-g23ad0f0-gdb-logs.tar.xz
.
├── 0001-free_realized_face-printf-logs-for-lisp_string_width.patch
├── 00_before-segfaults
│   ├── 00_SEGFAULT-free_realized_face-gdb-grep-0x1032af4a0.txt
│   ├── 00_SEGFAULT-free_realized_face-gdb.txt.bz2
│   ├── 01_SEGFAULT-free_realized_face-gdb-grep-0x103435210.txt
│   ├── 01_SEGFAULT-free_realized_face-gdb.txt.bz2
│   ├── 10_NO-SEGFAULT-free_realized_face-gdb-grep-0x1032cb260.txt
│   ├── 10_NO-SEGFAULT-free_realized_face-gdb.txt.bz2
│   ├── 11_NO-SEGFAULT-free_realized_face-gdb-grep-0x1031a5880.txt
│   ├── 11_NO-SEGFAULT-free_realized_face-gdb.txt.bz2
│   ├── after-lisp_string_width-autocmp.png
│   └── emacs_crash-lisp_string_width-gdb_bt_full-with-pp.png
├── 10_after
│   ├── lisp_string_width-g23ad0f0-gdb-00-grep-0x10cf4fff0.txt
│   ├── lisp_string_width-g23ad0f0-gdb-00-grep-0x13e378a40.txt
│   ├── lisp_string_width-g23ad0f0-gdb-00-grep-0x7ffeefbef230.txt
│   ├── lisp_string_width-g23ad0f0-gdb-00-grep-0x7ffeefbf2c30.txt
│   ├── lisp_string_width-g23ad0f0-gdb-00-grep-0x7ffeefbf5ac0.txt
│   ├── lisp_string_width-g23ad0f0-gdb-00-grep-0x7ffeefbf8ea0.txt
│   ├── lisp_string_width-g23ad0f0-gdb-00-grep-0x7ffeefbf9e90.txt
│   ├── lisp_string_width-g23ad0f0-gdb-00-grep-0x7ffeefbfa140.txt
│   ├── lisp_string_width-g23ad0f0-gdb-00.txt
│   ├── lisp_string_width-g23ad0f0-gdb-01.txt
│   ├── lisp_string_width-g23ad0f0-gdb-03.txt
│   ├── lisp_string_width-g23ad0f0-gdb-04.txt
│   ├── lisp_string_width-g23ad0f0-gdb-05.txt
│   ├── lisp_string_width-g23ad0f0-gdb-06.txt
│   ├── lisp_string_width-g23ad0f0-gdb-07.txt
│   ├── lisp_string_width-g23ad0f0-gdb-08.txt
│   └── lisp_string_width-g23ad0f0-gdb-09.txt
├── VERIFICATION_RESULT.txt
├── dot.gdbinit
└── init.el

logging patch:
  0001-free_realized_face-printf-logs-for-lisp_string_width.patch

init.el:
--------------------------------------------------------------------------------
(custom-set-variables
 '(tramp-syntax 'default nil (tramp)))
--------------------------------------------------------------------------------


Bug48732-lisp_string_width-g23ad0f0-gdb-logs/10_after/lisp_string_width-g23ad0f0-gdb-00.txt
--------------------------------------------------------------------------------
GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin20.3.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./src/emacs...
(gdb) r
Starting program: /Users/naofumi/_git/git.sv.gnu.org/emacs/src/emacs 
[New Thread 0x2403 of process 17361]
[New Thread 0x2303 of process 17361]
warning: unhandled dyld version (17)
realize_face: make_realized_face: face=0x103109560: face->lface=0x103109560
realize_face: make_realized_face: face=0x103109680: face->lface=0x103109680
realize_face: make_realized_face: face=0x1031097a0: face->lface=0x1031097a0
realize_face: make_realized_face: face=0x1031098c0: face->lface=0x1031098c0
realize_face: make_realized_face: face=0x1031099e0: face->lface=0x1031099e0
realize_face: make_realized_face: face=0x103109b00: face->lface=0x103109b00
realize_face: make_realized_face: face=0x103109c20: face->lface=0x103109c20
realize_face: make_realized_face: face=0x103109d40: face->lface=0x103109d40
realize_face: make_realized_face: face=0x103109e60: face->lface=0x103109e60
realize_face: make_realized_face: face=0x103109f80: face->lface=0x103109f80
realize_face: make_realized_face: face=0x10310a0a0: face->lface=0x10310a0a0
realize_face: make_realized_face: face=0x10310a1c0: face->lface=0x10310a1c0
realize_face: make_realized_face: face=0x10310a2e0: face->lface=0x10310a2e0
realize_face: make_realized_face: face=0x10310a400: face->lface=0x10310a400
realize_face: make_realized_face: face=0x10310a520: face->lface=0x10310a520
realize_face: make_realized_face: face=0x10310a640: face->lface=0x10310a640
realize_face: make_realized_face: face=0x10310a760: face->lface=0x10310a760
realize_face: make_realized_face: face=0x10310a880: face->lface=0x10310a880
realize_face: make_realized_face: face=0x10310a9a0: face->lface=0x10310a9a0
xfree: block=0x103226150

[..snip..]

xfree: block=0x103945c00
free_all_realized_faces: ! NILP (frame)
free_realized_faces: frame f=0x10509f830: c->faces_by_id[i]
free_realized_face: frame f=0x10509f830: face=0x1031ee8c0
xfree: block=0x1031ee8c0
free_realized_faces: frame f=0x10509f830: c->faces_by_id[i]
free_realized_face: frame f=0x10509f830: face=0x1031c4c90
xfree: block=0x1031c4c90
free_realized_faces: frame f=0x10509f830: c->faces_by_id[i]
free_realized_face: frame f=0x10509f830: face=0x103169620
xfree: block=0x103169620
free_realized_faces: frame f=0x10509f830: c->faces_by_id[i]
free_realized_face: frame f=0x10509f830: face=0x10316bc80
xfree: block=0x10316bc80
free_realized_faces: frame f=0x10509f830: c->faces_by_id[i]
free_realized_face: frame f=0x10509f830: face=0x10316c4c0
xfree: block=0x10316c4c0
free_realized_faces: frame f=0x10509f830: c->faces_by_id[i]
free_realized_face: frame f=0x10509f830: face=0x1031ef160
xfree: block=0x1031ef160
free_realized_faces: frame f=0x10509f830: c->faces_by_id[i]
free_realized_face: frame f=0x10509f830: face=0x1033231e0
xfree: block=0x1033231e0
free_realized_faces: frame f=0x10509f830: c->faces_by_id[i]
free_realized_face: frame f=0x10509f830: face=0x103324f10
xfree: block=0x103324f10
free_realized_faces: frame f=0x10509f830: c->faces_by_id[i]
free_realized_face: frame f=0x10509f830: face=0x1033254f0
xfree: block=0x1033254f0
free_realized_faces: frame f=0x10509f830: c->faces_by_id[i]
free_realized_face: frame f=0x10509f830: face=0x103325ad0
xfree: block=0x103325ad0
free_realized_faces: frame f=0x10509f830: c->faces_by_id[i]
free_realized_face: frame f=0x10509f830: face=0x1033260b0
xfree: block=0x1033260b0
free_realized_faces: frame f=0x10509f830: c->faces_by_id[i]
free_realized_face: frame f=0x10509f830: face=0x103326690
xfree: block=0x103326690
free_realized_faces: frame f=0x10509f830: c->faces_by_id[i]
free_realized_face: frame f=0x10509f830: face=0x103326c70
xfree: block=0x103326c70
free_realized_faces: frame f=0x10509f830: c->faces_by_id[i]
free_realized_face: frame f=0x10509f830: face=0x1033274b0
xfree: block=0x1033274b0
free_realized_faces: frame f=0x10509f830: c->faces_by_id[i]
free_realized_face: frame f=0x10509f830: face=0x103327cf0
xfree: block=0x103327cf0
free_realized_faces: frame f=0x10509f830: c->faces_by_id[i]
free_realized_face: frame f=0x10509f830: face=0x103328530
xfree: block=0x103328530
free_realized_faces: frame f=0x10509f830: c->faces_by_id[i]
free_realized_face: frame f=0x10509f830: face=0x103328b10
xfree: block=0x103328b10
free_realized_faces: frame f=0x10509f830: c->faces_by_id[i]
free_realized_face: frame f=0x10509f830: face=0x1033290f0
xfree: block=0x1033290f0
free_realized_faces: frame f=0x10509f830: c->faces_by_id[i]
free_realized_face: frame f=0x10509f830: face=0x1031f2d90
xfree: block=0x1031f2d90
realize_gui_face: make_realized_face: face=0x103169620: face->lface=0x103169620
xfree: block=0x1049a4000
realize_face: realize_gui_face: face=0x103169620: face->lface=0x103169620
realize_gui_face: make_realized_face: face=0x1031c4c90: face->lface=0x1031c4c90
realize_face: realize_gui_face: face=0x1031c4c90: face->lface=0x1031c4c90
realize_gui_face: make_realized_face: face=0x10316a9c0: face->lface=0x10316a9c0
font_select_entity: frame f=0x10509f830: attrs=0x7ffeefbf2c30
xfree: block=0x104114c00
realize_face: realize_gui_face: face=0x10316a9c0: face->lface=0x10316a9c0
realize_gui_face: make_realized_face: face=0x1032dcc20: face->lface=0x1032dcc20
realize_face: realize_gui_face: face=0x1032dcc20: face->lface=0x1032dcc20
realize_gui_face: make_realized_face: face=0x1032dd460: face->lface=0x1032dd460
realize_face: realize_gui_face: face=0x1032dd460: face->lface=0x1032dd460
realize_gui_face: make_realized_face: face=0x1032ddca0: face->lface=0x1032ddca0
realize_face: realize_gui_face: face=0x1032ddca0: face->lface=0x1032ddca0
realize_gui_face: make_realized_face: face=0x1032de740: face->lface=0x1032de740
realize_face: realize_gui_face: face=0x1032de740: face->lface=0x1032de740
realize_gui_face: make_realized_face: face=0x1032ded20: face->lface=0x1032ded20
realize_face: realize_gui_face: face=0x1032ded20: face->lface=0x1032ded20
realize_gui_face: make_realized_face: face=0x1032df300: face->lface=0x1032df300
realize_face: realize_gui_face: face=0x1032df300: face->lface=0x1032df300
realize_gui_face: make_realized_face: face=0x1032df8e0: face->lface=0x1032df8e0
realize_face: realize_gui_face: face=0x1032df8e0: face->lface=0x1032df8e0
realize_gui_face: make_realized_face: face=0x1032dfec0: face->lface=0x1032dfec0
realize_face: realize_gui_face: face=0x1032dfec0: face->lface=0x1032dfec0
realize_gui_face: make_realized_face: face=0x1032e04a0: face->lface=0x1032e04a0
realize_face: realize_gui_face: face=0x1032e04a0: face->lface=0x1032e04a0
realize_gui_face: make_realized_face: face=0x1032e0a80: face->lface=0x1032e0a80
realize_face: realize_gui_face: face=0x1032e0a80: face->lface=0x1032e0a80
realize_gui_face: make_realized_face: face=0x1032e12c0: face->lface=0x1032e12c0
realize_face: realize_gui_face: face=0x1032e12c0: face->lface=0x1032e12c0
realize_gui_face: make_realized_face: face=0x1032e1b00: face->lface=0x1032e1b00
realize_face: realize_gui_face: face=0x1032e1b00: face->lface=0x1032e1b00
realize_gui_face: make_realized_face: face=0x1032e2340: face->lface=0x1032e2340
realize_face: realize_gui_face: face=0x1032e2340: face->lface=0x1032e2340
realize_gui_face: make_realized_face: face=0x1032e2920: face->lface=0x1032e2920
realize_face: realize_gui_face: face=0x1032e2920: face->lface=0x1032e2920
realize_gui_face: make_realized_face: face=0x1032e2f00: face->lface=0x1032e2f00
font_select_entity: frame f=0x10509f830: attrs=0x7ffeefbf2c30
realize_face: realize_gui_face: face=0x1032e2f00: face->lface=0x1032e2f00
realize_gui_face: make_realized_face: face=0x1032e3740: face->lface=0x1032e3740
font_select_entity: frame f=0x10509f830: attrs=0x7ffeefbf2c30
realize_face: realize_gui_face: face=0x1032e3740: face->lface=0x1032e3740
xfree: block=0x1032e4460

[..snip..]

[Inferior 1 (process 17361) exited normally]
(gdb) q
--------------------------------------------------------------------------------


In GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin20.5.0, NS appkit-2022.50 Version 11.4 (Build 20F71))
 of 2021-05-30 built on hyperion.local
Repository revision: 23ad0f0c5adbeda9a0bd346138e2950cb5e5a136
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.4

Configured using:
 'configure --prefix=/Users/naofumi/.local/emacs-head 'CFLAGS=-O0 -g3''

Configured features:
ACL DBUS GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
KQUEUE NS PDUMPER PNG RSVG THREADS TIFF TOOLKIT_SCROLL_BARS XIM ZLIB

Important settings:
  value of $LANG: ja_JP.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs text-property-search mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils tramp tramp-loaddefs
trampver tramp-integration files-x tramp-compat shell pcomplete comint
ansi-color ring parse-time iso8601 time-date ls-lisp format-spec
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs cl-loaddefs
cl-lib password-cache json subr-x map seq byte-opt bytecomp byte-compile
cconv gv japan-util iso-transl tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/ns-win ns-win
ucs-normalize mule-util term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
kqueue cocoa ns lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 64676 70998)
 (symbols 48 7901 68)
 (strings 32 22224 8156)
 (string-bytes 1 761506)
 (vectors 16 16018)
 (vector-slots 8 270817 93429)
 (floats 8 30 250)
 (intervals 56 200 91)
 (buffers 992 11))

[Bug48732-lisp_string_width-g23ad0f0-gdb-logs.tar.xz (application/x-xz, attachment)]

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

Message #25 received at 48732-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Naofumi Yasufuku <naofumi <at> yasufuku.dev>
Cc: 48732-done <at> debbugs.gnu.org
Subject: Re: bug#48732: 28.0.50; lisp_string_width segfaults on startup under
 macOS
Date: Mon, 31 May 2021 19:25:01 +0300

> From: Naofumi Yasufuku <naofumi <at> yasufuku.dev>
> Date: Mon, 31 May 2021 23:27:02 +0900
> Cc: 48732 <at> debbugs.gnu.org
> 
> This workaround works fine.  I think this issue can be closed.
> 
> Access to unrealized 'face->lface' Lisp_Object is not seen anymore
> on startup, and no segfault happens with both simple reproducing
> 'tramp-syntax’ init.el and my daily-use more complicated init.el.
> 
> I comfirmed it on two intel macs which this segfault was observed:
>   - MacBook running the latest macOS 11.4
>   - Mac mini running macOS 10.14
> 
> At the same time, font corruption issue with some themes is also disappeared
> as Pankaj said on emacs-devel list.
> (After autocmp string-width commits, I had seen the font corruption
> issue frequently with doom-tomorrow-night of doom-themes package.)

Thanks for testing.

I think the problem was in styled_format: it keeps C pointers to Lisp
string data around the call to lisp_string_width, which could cause
GC, which could relocate Lisp strings.  But after the last change,
lisp_string_width as called from styled_format can no longer cause GC,
so that problem is gone.  And there are other valid reasons why
'format' and 'format-message' are better without this feature, so I
think we will leave it at that.

Previous Next

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