GNU bug report logs -
#76517
31.0.50; feature/igc 6ff509af3d31 crash on Wayland KDE, (with -g3
Previous Next
Reported by: Eval Exec <execvy <at> gmail.com>
Date: Mon, 24 Feb 2025 02:28:02 UTC
Severity: normal
Found in version 31.0.50
Done: Pip Cet <pipcet <at> protonmail.com>
Bug is archived. No further changes may be made.
Full log
Message #32 received at 76517 <at> debbugs.gnu.org (full text, mbox):
> Cc: 76517 <at> debbugs.gnu.org
> Date: Mon, 24 Feb 2025 15:49:38 +0000
> From: Pip Cet via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> "Eval Exec" <execvy <at> gmail.com> writes:
>
> > Hello,
> > I'm helping to test feature/igc branch
>
> Thanks for the report!
>
> At first glance, the problem doesn't seem to be specific to feature/igc.
>
> > #16 0x00000000004933d8 in c_string_width (nbytes=<synthetic pointer>,
> > nchars=<synthetic pointer>, precision=<optimized out>, len=69,
> > str=0x7f1ec16860fa "\274\214我中间使用 充电宝给电脑冲了一次电。还行。。。") at
>
> This string starts with an incomplete character sequence.
The evaluation of the header-line-format shows the complete string.
> As the screenshot at https://imgur.com/a/tON6P7w (why a screenshot?)
> shows, the last character before that is "%", followed by what looks
> like "，", a fullwidth comma.
>
> It seems the "%" was interpreted as introducing a mode line escape,
> which used the first byte of the three-byte encoding used for the
> fullwidth comma. The remaining bytes were then interpreted as the
> beginning of a multi-byte character, which ended up out of range and
> accessing an element of the display_table_ chartab which wasn't defined.
>
> So I guess our mode line escapes need to be fixed for multibyte
> characters, and hopefully no further action is necessary (you might also
> want to consider not making mode line escapes part of your header
> lines).
I don't see any "%", but are you saying that some UTF-8 byte sequence
of a non-ASCII character that is not the character '%' itself could
have the '%' byte as part of it? I thought that was impossible,
guaranteed by the way UTF-8 sequences are produced. AFAIK, ASCII
bytes can only happen as themselves in UTF-8 encoding. So when we see
'%', it cannot be anything but the ASCII chyaracter '%'.
Or what am I missing?
This bug report was last modified 131 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.