[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#48732: 28.0.50; lisp_string_width segfaults on startup under macOS
From: |
Eli Zaretskii |
Subject: |
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@yasufuku.dev>
> Date: Sun, 30 May 2021 07:10:30 +0900
> Cc: 48732@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.