GNU bug report logs -
#36507
27.0.50; Crash on evaluating invalid UTF-8 byte sequence on MacOS
Previous Next
Reported by: Stefan Kangas <stefan <at> marxist.se>
Date: Fri, 5 Jul 2019 02:05:02 UTC
Severity: normal
Found in version 27.0.50
Done: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Bug is archived. No further changes may be made.
Full log
Message #16 received at 36507-done <at> debbugs.gnu.org (full text, mbox):
On Fri, 05 Jul 2019 20:36:34 +0900,
Stefan Kangas wrote:
>
> YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp> writes:
> > > > (decode-coding-string "\xE3\x32\x9A\x36" 'chinese-gb18030)
> > >
> > > I think the issue as such is beyond me, but I can reproduce this every time.
> > > Please let me know if you need help testing or more information.
> > >
> > > Before crash, I get this output:
> > > Thread 1 received signal SIGSEGV, Segmentation fault.
> > > 0x00007fff8ddbd326 in CFCharacterSetIsLongCharacterMember () from
> > > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
> >
> > Please try the patch below.
>
> The patch works; I no longer get the crash. The return value is now:
>
> "#(" " 0 1 (charset gb18030-4-byte-ext-2))"
Thanks. I pushed the patch to master and the emacs-26 branch as
0e15bd11dc0 and f0db687a285, respectively. (I forgot to add the bug
ID to commit log for the former.) Closing the bug.
> Note that the " " is a visually wide white space character that I
> can't copy to other programs for some reason. It is here replaced
> with a space. Not sure if this is expected or not.
On the Mac port, from which macfont.m originally came, the character
is displayed with boxed hexadecimal. So, this would be another issue
specific to the NS port.
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
This bug report was last modified 5 years and 316 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.