From: Eli Zaretskii <eliz@gnu.org>
To: Naofumi Yasufuku <naofumi@yasufuku.dev>
Cc: 48732-done@debbugs.gnu.org
Subject: bug#48732: 28.0.50; lisp_string_width segfaults on startup under macOS
Date: Mon, 31 May 2021 19:25:01 +0300 [thread overview]
Message-ID: <83v96y27mq.fsf@gnu.org> (raw)
In-Reply-To: <E477C7B7-C596-409B-8146-ABE839D88500@yasufuku.dev> (message from Naofumi Yasufuku on Mon, 31 May 2021 23:27:02 +0900)
> From: Naofumi Yasufuku <naofumi@yasufuku.dev>
> Date: Mon, 31 May 2021 23:27:02 +0900
> Cc: 48732@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.
prev parent reply other threads:[~2021-05-31 16:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-29 19:28 bug#48732: 28.0.50; lisp_string_width segfaults on startup under macOS Naofumi Yasufuku
2021-05-29 20:32 ` Eli Zaretskii
2021-05-29 22:10 ` Naofumi Yasufuku
2021-05-30 8:38 ` Eli Zaretskii
2021-05-30 9:06 ` Naofumi Yasufuku
2021-05-31 14:27 ` Naofumi Yasufuku
2021-05-31 16:25 ` Eli Zaretskii [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83v96y27mq.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=48732-done@debbugs.gnu.org \
--cc=naofumi@yasufuku.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).