bug#48732: 28.0.50; lisp_string_width segfaults on startup under macOS

[Naofumi Yasufuku]

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@hyperion emacs (master)]% pwd
/Users/naofumi/_git/git.sv.gnu.org/emacs
[naofumi@hyperion emacs (master)]% 
[naofumi@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@hyperion emacs (master)]% 
[naofumi@hyperion emacs (master)]% 
[naofumi@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
Description: BZip2 compressed data

> 2021/05/30 5:32、Eli Zaretskii <eliz@gnu.org>のメール:
> 
>> From: Naofumi Yasufuku <naofumi@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.