GNU bug report logs - #34826
Possible bug on "define-charset" of Emacs 27.0.50

Previous Next

Package: emacs;

Reported by: Ikki Tachikawa <tckwik <at> gmail.com>

Date: Tue, 12 Mar 2019 13:45:02 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34826 in the body.
You can then email your comments to 34826 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#34826; Package emacs. (Tue, 12 Mar 2019 13:45:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ikki Tachikawa <tckwik <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 12 Mar 2019 13:45:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ikki Tachikawa <tckwik <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Possible bug on "define-charset" of Emacs 27.0.50
Date: Tue, 12 Mar 2019 19:36:29 +0900
[Message part 1 (text/plain, inline)]
 Dear developers,

Perhaps at the following code, Emacs 27.0.50 (newest HEAD Windows version)
fails.
It works fine with Emacs 26.1.  Perhaps it happens independent of platform.

    (define-charset 'adobe-japan1 "Adobe-Japan1"
      :map (file-name-sans-extension aj16map)
      :invalid-code 128)))

Thread 1 received signal SIGSEGV, Segmentation fault.
0x00000004001c3042 in assq_no_quit (key=XIL(0xfffffffc04270ab0),
    list=XIL(0x100000000ff)) at fns.c:1607
1607        if (CONSP (XCAR (list)) && EQ (XCAR (XCAR (list)), key))
(gdb) bt
#0  0x00000004001c3042 in assq_no_quit (key=XIL(0xfffffffc04270ab0),
    list=XIL(0x100000000ff)) at fns.c:1607
#1  0x000000040019a32c in swap_in_symval_forwarding (symbol=0x49647b0,
    blv=0x509fb60) at data.c:1222
#2  0x000000040019a479 in find_symbol_value (symbol=XIL(0xfffffffc04270ab0))
    at data.c:1257
#3  0x000000040019a4dc in Fsymbol_value (symbol=XIL(0xfffffffc04270ab0))
    at data.c:1274
#4  0x000000040012f80d in set_buffer_internal_2 (b=0x4b4fbd0) at
buffer.c:2136
#5  0x000000040012f6f7 in set_buffer_internal_1 (b=0x469d648) at
buffer.c:2085
#6  0x0000000400102752 in set_buffer_internal (b=0x469d648) at buffer.h:1137
#7  0x00000004000c4ec2 in make_conversion_work_buffer (multibyte=true)
    at coding.c:7832
#8  0x00000004000c4f7f in code_conversion_save (with_work_buf=true,
    multibyte=true) at coding.c:7860
#9  0x00000004000c5cd2 in decode_coding_object (coding=0xbfb010,
    src_object=XIL(0x64c6764), from=0, from_byte=0, to=20, to_byte=20,
    dst_object=XIL(0xd200)) at coding.c:8106
#10 0x00000004000cae51 in code_convert_string (string=XIL(0x64c6764),
    coding_system=XIL(0xe760), dst_object=XIL(0xd200), encodep=false,
    nocopy=false, norecord=true) at coding.c:9468
#11 0x00000004000caf13 in code_convert_string_norecord (
    string=XIL(0x64c6764), coding_system=XIL(0xe760), encodep=false)
    at coding.c:9488
#12 0x00000004000caf6c in decode_file_name (fname=XIL(0x64c6764))
    at coding.c:9501
#13 0x000000040014c901 in Fexpand_file_name (name=XIL(0x64c6744),
    default_directory=XIL(0x508d1d4)) at fileio.c:1105
#14 0x00000004001e8885 in openp (path=XIL(0x50899b3), str=XIL(0x64c6744),
    suffixes=XIL(0xbfb9b3), storeptr=0x0, predicate=XIL(0), newer=false)
    at lread.c:1613
#15 0x000000040009dd63 in load_charset_map_from_file (charset=0xbfbaf0,
    mapfile=XIL(0x64c6744), control_flag=0) at charset.c:489
#16 0x000000040009e498 in load_charset (charset=0xbfbaf0, control_flag=0)
    at charset.c:643
#17 0x00000004000a0ed4 in Fdefine_charset_internal (nargs=17, args=0xbfbea8)
    at charset.c:1169
#18 0x00000004001ba8e9 in funcall_subr (
    subr=0x400621300 <Sdefine_charset_internal>, numargs=17, args=0xbfbea8)
    at eval.c:2902
#19 0x00000004001ba5fb in Ffuncall (nargs=18, args=0xbfbea0) at eval.c:2847
#20 0x00000004001b9a1e in Fapply (nargs=3, args=0xbfc100) at eval.c:2467
#21 0x00000004001ba8e9 in funcall_subr (subr=0x40062b340 <Sapply>,
numargs=3,
    args=0xbfc100) at eval.c:2902
#22 0x00000004001ba5fb in Ffuncall (nargs=4, args=0xbfc0f8) at eval.c:2847
#23 0x00000004002089ff in exec_byte_code (bytestr=XIL(0x4b67164),
    vector=XIL(0x4b666ad), maxdepth=make_number(7), args_template=XIL(0),
    nargs=0, args=0x0) at bytecode.c:633
#24 0x00000004001bb33a in funcall_lambda (fun=XIL(0x4b6667d), nargs=6,
    arg_vector=0x4b666ad) at eval.c:3123
#25 0x00000004001bad71 in apply_lambda (fun=XIL(0x4b6667d),
    args=XIL(0x64c3983), count=40) at eval.c:2981
#26 0x00000004001b9391 in eval_sub (form=XIL(0x64c3953)) at eval.c:2360
#27 0x00000004001b514f in Fprogn (body=XIL(0)) at eval.c:478
#28 0x00000004001b8e12 in eval_sub (form=XIL(0x64c2673)) at eval.c:2267
#29 0x00000004001b5020 in Fif (args=XIL(0x64c2693)) at eval.c:433
#30 0x00000004001b8e12 in eval_sub (form=XIL(0x64c26a3)) at eval.c:2267
#31 0x00000004001b514f in Fprogn (body=XIL(0)) at eval.c:478
#32 0x00000004001b64c9 in Flet (args=XIL(0x64c2773)) at eval.c:1005
#33 0x00000004001b8e12 in eval_sub (form=XIL(0x64c2783)) at eval.c:2267
#34 0x00000004001e943b in readevalloop_eager_expand_eval
(val=XIL(0x64c4263),
    macroexpand=XIL(0xfffffffc04305a58)) at lread.c:1904
#35 0x00000004001e9daf in readevalloop (readcharfun=XIL(0x50e8885),
    infile0=0x0, sourcename=XIL(0x5dd98c4), printflag=false, unibyte=XIL(0),
    readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2087
#36 0x00000004001ea1f1 in Feval_buffer (buffer=XIL(0x50e8885),
    printflag=XIL(0), filename=XIL(0x50cd424), unibyte=XIL(0),
    do_allow_print=XIL(0xd200)) at lread.c:2154
#37 0x00000004001baa88 in funcall_subr (subr=0x40062de80 <Seval_buffer>,
    numargs=5, args=0xbfd040) at eval.c:2934
#38 0x00000004001ba5fb in Ffuncall (nargs=6, args=0xbfd038) at eval.c:2847
#39 0x00000004002089ff in exec_byte_code (bytestr=XIL(0x481f3b4),
    vector=XIL(0x481ec35), maxdepth=make_number(6), args_template=XIL(0),
    nargs=0, args=0x0) at bytecode.c:633
#40 0x00000004001bb33a in funcall_lambda (fun=XIL(0x481ec05), nargs=4,
    arg_vector=0x481ec35) at eval.c:3123
#41 0x00000004001ba63f in Ffuncall (nargs=5, args=0xbfd560) at eval.c:2849
#42 0x00000004001ba0ca in call4 (fn=XIL(0xfffffffc0412aed0),
    arg1=XIL(0x50cd424), arg2=XIL(0x50cd424), arg3=XIL(0xd200),
    arg4=XIL(0xd200)) at eval.c:2723
#43 0x00000004001e7f45 in Fload (file=XIL(0x50cd5c4),
    noerror=XIL(0xfffffffc0412b590), nomessage=XIL(0xfffffffc0412b3c0),
    nosuffix=XIL(0), must_suffix=XIL(0)) at lread.c:1381
#44 0x00000004001baa88 in funcall_subr (subr=0x40062de00 <Sload>, numargs=3,
    args=0xbfdd50) at eval.c:2934
#45 0x00000004001ba5fb in Ffuncall (nargs=4, args=0xbfdd48) at eval.c:2847
#46 0x00000004002089ff in exec_byte_code (bytestr=XIL(0x4bc47ec),
    vector=XIL(0x4bc4555), maxdepth=make_number(18),
    args_template=make_number(769), nargs=3, args=0xbfe2f8) at
bytecode.c:633
#47 0x00000004001bafde in funcall_lambda (fun=XIL(0x4bc4525), nargs=3,
    arg_vector=0xbfe2e0) at eval.c:3045
#48 0x00000004001ba63f in Ffuncall (nargs=4, args=0xbfe2d8) at eval.c:2849
#49 0x00000004002089ff in exec_byte_code (bytestr=XIL(0x4bc517c),
    vector=XIL(0x4bc19f5), maxdepth=make_number(12),
    args_template=make_number(0), nargs=0, args=0xbfedf8) at bytecode.c:633
#50 0x00000004001bafde in funcall_lambda (fun=XIL(0x4bc19c5), nargs=0,
    arg_vector=0xbfedf8) at eval.c:3045
#51 0x00000004001ba63f in Ffuncall (nargs=1, args=0xbfedf0) at eval.c:2849
#52 0x00000004002089ff in exec_byte_code (bytestr=XIL(0x4bc5cec),
    vector=XIL(0x4bc534d), maxdepth=make_number(12),
    args_template=make_number(0), nargs=0, args=0xbff3e0) at bytecode.c:633
#53 0x00000004001bafde in funcall_lambda (fun=XIL(0x4bc531d), nargs=0,
    arg_vector=0xbff3e0) at eval.c:3045
#54 0x00000004001bad71 in apply_lambda (fun=XIL(0x4bc531d), args=XIL(0),
    count=4) at eval.c:2981
#55 0x00000004001b9391 in eval_sub (form=XIL(0x4d1bab3)) at eval.c:2360
#56 0x00000004001b8814 in Feval (form=XIL(0x4d1bab3), lexical=XIL(0))
    at eval.c:2134
#57 0x00000004001090c0 in top_level_2 () at keyboard.c:1099
#58 0x00000004001b6e9e in internal_condition_case (
    bfun=0x400109095 <top_level_2>, handlers=XIL(0x52e0),
    hfun=0x4001089df <cmd_error>) at eval.c:1369
#59 0x0000000400109118 in top_level_1 (ignore=XIL(0)) at keyboard.c:1107
#60 0x00000004001b6769 in internal_catch (tag=XIL(0xda70),
    func=0x4001090c6 <top_level_1>, arg=XIL(0)) at eval.c:1132
#61 0x0000000400108f94 in command_loop () at keyboard.c:1068
#62 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Lisp Backtrace:
"define-charset-internal" (0xbfbea8)
"apply" (0xbfc100)
"define-charset" (0xbfc620)
"progn" (0xbfc8b0)
"if" (0xbfca30)
"let" (0xbfcc80)
"eval-buffer" (0xbfd040)
"load-with-code-conversion" (0xbfd568)
"load" (0xbfdd50)
"startup--load-user-init-file" (0xbfe2e0)
"command-line" (0xbfedf8)
"normal-top-level" (0xbff3e0)

Regards,
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34826; Package emacs. (Tue, 12 Mar 2019 16:11:02 GMT) Full text and rfc822 format available.

Message #8 received at 34826 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ikki Tachikawa <tckwik <at> gmail.com>
Cc: 34826 <at> debbugs.gnu.org
Subject: Re: bug#34826: Possible bug on "define-charset" of Emacs 27.0.50
Date: Tue, 12 Mar 2019 18:09:48 +0200
> From: Ikki Tachikawa <tckwik <at> gmail.com>
> Date: Tue, 12 Mar 2019 19:36:29 +0900
> 
> Perhaps at the following code, Emacs 27.0.50 (newest HEAD Windows version) fails.
> It works fine with Emacs 26.1.  Perhaps it happens independent of platform.
> 
>     (define-charset 'adobe-japan1 "Adobe-Japan1"
>       :map (file-name-sans-extension aj16map)
>       :invalid-code 128)))

What is aj16map?  I guess it's a variable that holds the name of a map
file?  Please show that file as well, as otherwise it's impossible to
reproduce and investigate this issue.

Thanks.




Reply sent to Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility. (Sun, 17 Mar 2019 15:53:01 GMT) Full text and rfc822 format available.

Notification sent to Ikki Tachikawa <tckwik <at> gmail.com>:
bug acknowledged by developer. (Sun, 17 Mar 2019 15:53:01 GMT) Full text and rfc822 format available.

Message #13 received at 34826-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ikki Tachikawa <tckwik <at> gmail.com>
Cc: 34826-done <at> debbugs.gnu.org
Subject: Re: bug#34826: Possible bug on "define-charset" of Emacs 27.0.50
Date: Sun, 17 Mar 2019 17:52:19 +0200
> From: Ikki Tachikawa <tckwik <at> gmail.com>
> Date: Tue, 12 Mar 2019 19:36:29 +0900
> 
> Perhaps at the following code, Emacs 27.0.50 (newest HEAD Windows version) fails.
> It works fine with Emacs 26.1.  Perhaps it happens independent of platform.
> 
>     (define-charset 'adobe-japan1 "Adobe-Japan1"
>       :map (file-name-sans-extension aj16map)
>       :invalid-code 128)))

This was a bug introduced when we switched to using the portable
dumping: an attempt to create any additional charset after restoring
from a pdump file would crash.

Should be fixed now.

Thanks.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 15 Apr 2019 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 5 years and 12 days ago.

Previous Next


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