GNU bug report logs - #76517
31.0.50; feature/igc 6ff509af3d31 crash on Wayland KDE, (with -g3

Previous Next

Package: emacs;

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


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: execvy <at> gmail.com, 76517 <at> debbugs.gnu.org
Subject: bug#76517: 31.0.50; feature/igc 6ff509af3d31 crash on Wayland KDE, (with -g3
Date: Mon, 24 Feb 2025 18:06:51 +0200
> 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 132 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.