From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#37385: 27.0.50; Crash on multibyte assertion violation Date: Thu, 12 Sep 2019 16:01:56 +0300 Message-ID: <83ftl11xdn.fsf@gnu.org> References: <87tv9ir38c.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="67259"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 37385@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 12 15:02:22 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i8Ojt-000HGW-Cq for geb-bug-gnu-emacs@m.gmane.org; Thu, 12 Sep 2019 15:02:21 +0200 Original-Received: from localhost ([::1]:34304 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i8Ojr-0006ah-UW for geb-bug-gnu-emacs@m.gmane.org; Thu, 12 Sep 2019 09:02:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59294) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i8Ojd-0006Uy-Eh for bug-gnu-emacs@gnu.org; Thu, 12 Sep 2019 09:02:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i8Ojc-0003IW-67 for bug-gnu-emacs@gnu.org; Thu, 12 Sep 2019 09:02:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34347) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i8Ojc-0003II-2P for bug-gnu-emacs@gnu.org; Thu, 12 Sep 2019 09:02:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1i8Ojb-0002VT-VH for bug-gnu-emacs@gnu.org; Thu, 12 Sep 2019 09:02:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Sep 2019 13:02:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37385 X-GNU-PR-Package: emacs Original-Received: via spool by 37385-submit@debbugs.gnu.org id=B37385.15682933189623 (code B ref 37385); Thu, 12 Sep 2019 13:02:03 +0000 Original-Received: (at 37385) by debbugs.gnu.org; 12 Sep 2019 13:01:58 +0000 Original-Received: from localhost ([127.0.0.1]:43168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i8OjW-0002V9-3P for submit@debbugs.gnu.org; Thu, 12 Sep 2019 09:01:58 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:50666) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i8OjT-0002Uv-1r for 37385@debbugs.gnu.org; Thu, 12 Sep 2019 09:01:55 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33574) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i8OjN-00037B-Il; Thu, 12 Sep 2019 09:01:49 -0400 Original-Received: from [176.228.60.248] (port=2432 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i8OjI-0000tz-EI; Thu, 12 Sep 2019 09:01:47 -0400 In-reply-to: <87tv9ir38c.fsf@mail.linkov.net> (message from Juri Linkov on Wed, 11 Sep 2019 23:24:03 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:166369 Archived-At: > From: Juri Linkov > Date: Wed, 11 Sep 2019 23:24:03 +0300 > > Configured using: > 'configure --with-x-toolkit=no --enable-checking=yes,glyphs > --enable-check-lisp-object-type 'CFLAGS=-O0 -g3'' > > These steps reproduce the crash in master: > > 0. emacs -Q > 1. Eval: (define-key global-map [menu-bar test] '("Test ⮿" keymap)) > 2. Visit an image file, e.g. etc/images/attach.pbm > > #0 0x00005555557a61b8 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:374 > #1 0x00005555558c7555 in die (msg=0x555555ae73ee "SINGLE_BYTE_CHAR_P (c)", file=0x555555ae4790 "xdisp.c", line=7250) at alloc.c:7256 > #2 0x00005555555e9e56 in get_next_display_element (it=0x7fffffff89b0) at xdisp.c:7250 > #3 0x000055555562938c in display_string (string=0x0, lisp_string=XIL(0x5555567a0204), face_string=XIL(0), face_string_pos=0, start=0, it=0x7fffffff89b0, field_width=7, precision=0, max_x=674, multibyte=-1) at xdisp.c:25489 > [...] > An assertion violation is in get_next_display_element: > > if (! it->multibyte_p && ! ASCII_CHAR_P (c)) > { > eassert (SINGLE_BYTE_CHAR_P (c)); > > The menu item uses a multibyte char: > > c = 11199 (#o25677, #x2bbf, ?⮿) > > But init_iterator sets multibyte_p in the menu-bar window to the > value of enable-multibyte-characters in the current buffer where > enable-multibyte-characters is nil when an image file is visited in > image-mode: > > /* Are multibyte characters enabled in current_buffer? */ > it->multibyte_p = !NILP (BVAR (current_buffer, enable_multibyte_characters)); > > I tried the following fix and it prevents the crash: Thanks, but this is a backward-incompatible change on too low a level. It is a long-standing "convention" in Emacs that Lisp strings rendered as part of, or in relation to, unibyte buffers are assumed unibyte by default, and I don't want to change that -- who knows how many places in the code rely on this implicit assumption? Also, the change in reseat_1 looks unnecessary, as I'd be surprised if that function was called in your use case (reseat_1 is used only when displaying buffers, not strings). Please try an alternative patch below. (I don't have access to an X build without a toolkit, so I cannot test this myself.) Stepping a notch back, I cannot say I like this "non-ASCII art" implementation for tabs. It has two annoying problems: . it looks unprofessional on GUI frames . it requires you to determine whether the frame/font used for the menu can display this character, which is not easy Why not use an image of a plus sign on GUI frames, and a simple ASCII "+" on TTY frames and frames that have no image support? I think the result will be much better. Thanks. diff --git a/src/xdisp.c b/src/xdisp.c index 94f969f..d342da5 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -12994,7 +12994,8 @@ redisplay_tool_bar (struct frame *f) /* Build a string that represents the contents of the tool-bar. */ build_desired_tool_bar_string (f); - reseat_to_string (&it, NULL, f->desired_tool_bar_string, 0, 0, 0, -1); + reseat_to_string (&it, NULL, f->desired_tool_bar_string, + 0, 0, 0, STRING_MULTIBYTE (f->desired_tool_bar_string)); /* FIXME: This should be controlled by a user option. But it doesn't make sense to have an R2L tool bar if the menu bar cannot be drawn also R2L, and making the menu bar R2L is tricky due @@ -23531,7 +23532,7 @@ display_menu_bar (struct window *w) /* Display the item, pad with one space. */ if (it.current_x < it.last_visible_x) display_string (NULL, string, Qnil, 0, 0, &it, - SCHARS (string) + 1, 0, 0, -1); + SCHARS (string) + 1, 0, 0, STRING_MULTIBYTE (string)); } /* Fill out the line with spaces. */