Emacs segfaults when handling wrong_type_argument backtrace

Emacs segfaults when handling wrong_type_argument backtrace

[Jonas Jelten]

Hi!

I'm using emacs-29 at ab4273056e0ab68a27fe807b16e2995bf84b72ec with Doom Emacs with on Gentoo.

configured with:
./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --datarootdir=/usr/share --disable-silent-rules --docdir=/usr/share/doc/emacs-29.0.9999-r1 --htmldir=/usr/share/doc/emacs-29.0.9999-r1/html --libdir=/usr/lib64 --program-suffix=-emacs-29-vcs 
--includedir=/usr/include/emacs-29-vcs --infodir=/usr/share/info/emacs-29-vcs --localstatedir=/var --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp --without-compress-install --without-hesiod --without-pop --with-file-notification=inotify --with-pdumper --enable-acl --with-dbus --with-modules --with-gameuser=:gamestat --with-libgmp --with-gpm --with-native-compilation=aot --with-json 
--with-kerberos --with-kerberos5 --with-lcms2 --with-xml2 --with-mailutils --without-selinux --with-sqlite3 --with-gnutls --with-libsystemd --with-threads --without-tree-sitter --without-wide-int --with-sound=alsa --with-zlib --with-x --without-pgtk --without-ns --without-gconf --with-gsettings --with-toolkit-scroll-bars --with-xpm --with-xft --with-cairo --with-harfbuzz --without-libotf 
--without-m17n-flt --with-x-toolkit=gtk3 --without-xwidgets --with-gif --with-jpeg --with-png --with-rsvg --with-tiff --with-webp --with-imagemagick --with-dumping=pdumper

Launch with GDB:
gdb --args emacs --debug-init

= gdb>> source emacs/src/.gdbinit


When yasnippet triggers a backtrace, Emacs crashes:

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x000055555579d2a4 in PSEUDOVECTORP (code=<optimized out>, a=<optimized out>) at data.c:495
495	DEFUN ("byte-code-function-p", Fbyte_code_function_p, Sbyte_code_function_p,

= gdb>> disassemble
Dump of assembler code for function Fbyte_code_function_p:
    0x000055555579d290 <+0>:	lea    edx,[rdi-0x5]
    0x000055555579d293 <+3>:	xor    eax,eax
    0x000055555579d295 <+5>:	and    edx,0x7
    0x000055555579d298 <+8>:	jne    0x55555579d2be <Fbyte_code_function_p+46>
    0x000055555579d29a <+10>:	movabs rdx,0x400000003f000000
=> 0x000055555579d2a4 <+20>:	and    rdx,QWORD PTR [rdi-0x5]
    0x000055555579d2a8 <+24>:	movabs rcx,0x400000001e000000
    0x000055555579d2b2 <+34>:	cmp    rdx,rcx
    0x000055555579d2b5 <+37>:	mov    edx,0x30
    0x000055555579d2ba <+42>:	cmove  rax,rdx
    0x000055555579d2be <+46>:	ret
End of assembler dump.

= gdb>> i r
rax            0x0                 0
rbx            0x1                 1
rcx            0x5555558c29f8      93824995830264
rdx            0x400000003f000000  4611686019484352512
rsi            0x1                 1
rdi            0x5                 5
rbp            0x555555e39420      0x555555e39420 <freloc>
rsp            0x7fffffffbbc8      0x7fffffffbbc8
r8             0x7fffedd30648      140737183417928
r9             0x1                 1
r10            0x7fffed78b830      140737177499696
r11            0x555555d911c0      93825000870336
r12            0x5                 5
r13            0x7fffed797fa8      140737177550760
r14            0x7fffecbff240      140737165390400
r15            0x2aaa97f09d58      46912181935448
rip            0x55555579d2a4      0x55555579d2a4 <Fbyte_code_function_p+20>
eflags         0x10246             [ PF ZF IF RF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0

= gdb>> bt
#0  0x000055555579d2a4 in PSEUDOVECTORP (code=<optimized out>, a=<optimized out>) at data.c:495
#1  COMPILEDP (a=<optimized out>) at /usr/src/debug/app-editors/emacs-29.0.9999-r1/emacs/src/lisp.h:3060
#2  Fbyte_code_function_p (object=XIL(0x5)) at data.c:500
#3  Fbyte_code_function_p (object=XIL(0x5)) at data.c:495
#4  0x00007fffed78b860 in F6f636c6f737572652d74797065_oclosure_type_0 () at /usr/bin/../lib64/emacs/29.0.60/native-lisp/29.0.60-6fba8809/preloaded/oclosure-b279097d-e6802564.eln
#5  0x000055555581bcaa in exec_byte_code (fun=XIL(0x5), args_template=140737183417928, nargs=1, args=0x7fffecbff240) at bytecode.c:809
#6  0x00005555557bdb5a in Ffuncall (nargs=nargs@entry=3, args=0x7fffffffbd00) at eval.c:2995
#7  0x00005555557bde10 in Fapply (nargs=2, args=0x7fffecbff190) at eval.c:2666
#8  0x000055555581bcaa in exec_byte_code (fun=XIL(0x5), args_template=140737183417928, nargs=2, args=0x7fffecbff190) at bytecode.c:809
#9  0x00005555557bdb5a in Ffuncall (nargs=nargs@entry=4, args=0x7fffffffbea0) at eval.c:2995
#10 0x00005555557bde10 in Fapply (nargs=3, args=0x7fffecbff0e8) at eval.c:2666
#11 0x000055555581bcaa in exec_byte_code (fun=XIL(0x5), args_template=140737183417928, nargs=3, args=0x7fffecbff0e8) at bytecode.c:809
#12 0x00005555557bdb5a in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7fffecbff048) at eval.c:2995
#13 0x00005555557be09a in Fapply (nargs=3, args=0x7fffecbff048) at eval.c:2623
#14 0x000055555581bcaa in exec_byte_code (fun=XIL(0x5), args_template=140737183417928, nargs=3, args=0x7fffecbff048) at bytecode.c:809
#15 0x00005555557bdb5a in Ffuncall (nargs=3, args=0x7fffffffc1b0) at eval.c:2995
#16 0x00007fffc9c8484c in F636c2d7072696e31_cl_prin1_0 () at /usr/lib64/emacs/29.0.60/native-lisp/29.0.60-6fba8809/cl-print-79bf9fb1-a7af75d1.eln
#17 0x00005555557bdb5a in Ffuncall (nargs=3, args=0x7fffffffc260) at eval.c:2995
#18 0x00007fffc9c9b402 in F6261636b74726163652d2d7072696e74_backtrace__print_0 () at /usr/lib64/emacs/29.0.60/native-lisp/29.0.60-6fba8809/backtrace-f58a28c5-0f89deb7.eln
#19 0x00005555557bdb5a in Ffuncall (nargs=3, args=0x7fffffffc328) at eval.c:2995
#20 0x00007fffc9c84f05 in F636c2d7072696e742d746f2d737472696e672d776974682d6c696d6974_cl_print_to_string_with_limit_0 () at /usr/lib64/emacs/29.0.60/native-lisp/29.0.60-6fba8809/cl-print-79bf9fb1-a7af75d1.eln
#21 0x00005555557bdb5a in Ffuncall (nargs=4, args=0x7fffffffc430) at eval.c:2995
#22 0x00007fffc9c9a10b in F6261636b74726163652d2d7072696e742d746f2d737472696e67_backtrace__print_to_string_0 () at /usr/lib64/emacs/29.0.60/native-lisp/29.0.60-6fba8809/backtrace-f58a28c5-0f89deb7.eln
#23 0x00005555557bdb5a in Ffuncall (nargs=3, args=0x7fffffffc650) at eval.c:2995
#24 0x00007fffc9c9af42 in F6261636b74726163652d2d7072696e742d66756e632d616e642d61726773_backtrace__print_func_and_args_0 () at /usr/lib64/emacs/29.0.60/native-lisp/29.0.60-6fba8809/backtrace-f58a28c5-0f89deb7.eln
#25 0x00005555557bdb5a in Ffuncall (nargs=3, args=0x7fffffffc7d0) at eval.c:2995
#26 0x00007fffc9c9a3aa in F6261636b74726163652d7072696e742d6672616d65_backtrace_print_frame_0 () at /usr/lib64/emacs/29.0.60/native-lisp/29.0.60-6fba8809/backtrace-f58a28c5-0f89deb7.eln
#27 0x00005555557bdb5a in Ffuncall (nargs=3, args=0x7fffffffc8d0) at eval.c:2995
#28 0x00007fffc9c99daa in F6261636b74726163652d7072696e74_backtrace_print_0 () at /usr/lib64/emacs/29.0.60/native-lisp/29.0.60-6fba8809/backtrace-f58a28c5-0f89deb7.eln
#29 0x00005555557bdb5a in Ffuncall (nargs=1, args=0x7fffffffc998) at eval.c:2995
#30 0x00007fffc9cb118d in F64656275676765722d73657475702d627566666572_debugger_setup_buffer_0 () at /usr/lib64/emacs/29.0.60/native-lisp/29.0.60-6fba8809/debug-bee52b4d-63a033ac.eln
#31 0x00005555557bdb5a in Ffuncall (nargs=2, args=0x7fffffffcba8) at eval.c:2995
#32 0x00007fffc9cb031b in F6465627567_debug_0 () at /usr/lib64/emacs/29.0.60/native-lisp/29.0.60-6fba8809/debug-bee52b4d-63a033ac.eln
#33 0x00005555557bdb5a in Ffuncall (nargs=nargs@entry=3, args=0x7fffffffcc80) at eval.c:2995
#34 0x00005555557bde10 in Fapply (nargs=nargs@entry=2, args=args@entry=0x7fffffffcd20) at eval.c:2666
#35 0x00005555557bf059 in apply1 (arg=XIL(0x55555722b443), fn=<optimized out>) at eval.c:2882
#36 call_debugger (arg=XIL(0x55555722b443)) at eval.c:315
#37 0x00005555557bfe2d in maybe_call_debugger (data=XIL(0x55555722b8e3), sig=XIL(0x11f10), conditions=XIL(0x7fffee199c6b)) at eval.c:2026
#38 signal_or_quit (error_symbol=<optimized out>, data=<optimized out>, keyboard_quit=keyboard_quit@entry=false) at eval.c:1788
#39 0x00005555555a762f in Fsignal (error_symbol=<optimized out>, error_symbol@entry=XIL(0x11f10), data=<optimized out>) at eval.c:1685
#40 0x00005555555a7838 in xsignal (data=<optimized out>, error_symbol=XIL(0x11f10)) at /usr/src/debug/app-editors/emacs-29.0.9999-r1/emacs/src/lisp.h:4558
#41 xsignal2 (error_symbol=error_symbol@entry=XIL(0x11f10), arg1=arg1@entry=XIL(0xc5d0), arg2=arg2@entry=XIL(0x2aaa97f13420)) at eval.c:1884
#42 0x00005555555a632a in wrong_type_argument (predicate=predicate@entry=XIL(0xc5d0), value=value@entry=XIL(0x2aaa97f13420)) at data.c:143
#43 0x00005555555a6673 in CHECK_TYPE (x=XIL(0x2aaa97f13420), predicate=XIL(0xc5d0), ok=0) at /usr/src/debug/app-editors/emacs-29.0.9999-r1/emacs/src/lisp.h:794
#44 check_number_coerce_marker (x=XIL(0x2aaa97f13420)) at data.c:2691
#45 arithcompare (comparison=ARITH_EQUAL, num2=make_fixnum(0), num1=XIL(0x2aaa97f13420)) at data.c:2703
#46 arithcompare_driver (comparison=ARITH_EQUAL, args=0x7fffffffcf00, nargs=2) at data.c:2828
#47 Feqlsign (nargs=2, args=0x7fffffffcf00) at data.c:2838
#48 0x00007fffed6307ec in F666f72776172642d627574746f6e_forward_button_0 () at /usr/bin/../lib64/emacs/29.0.60/native-lisp/29.0.60-6fba8809/preloaded/button-747c9d6e-f1e1dcc9.eln
#49 0x00005555557bdb5a in Ffuncall (nargs=3, args=0x7fffffffd080) at eval.c:2995
#50 0x00007fffc9e887b9 in F7961732d2d706f73742d636f6d6d616e642d68616e646c6572_yas__post_command_handler_0 () at /home/jj/.emacs.d/.local/cache/eln/29.0.60-6fba8809/yasnippet-1c1d5a5d-8df7bbfb.eln
#51 0x00005555557bdb5a in Ffuncall (nargs=1, args=0x7fffffffd1a8) at eval.c:2995
#52 0x00005555557bb851 in internal_condition_case_n (bfun=bfun@entry=0x555555709520 <safe_run_hooks_1>, nargs=nargs@entry=2, args=args@entry=0x7fffffffd1a0, handlers=handlers@entry=XIL(0x30), hfun=hfun@entry=0x55555570ba60 <safe_run_hooks_error>)
     at eval.c:1558
#53 0x000055555570b1d3 in safe_run_hook_funcall (nargs=2, args=0x7fffffffd260) at keyboard.c:1891
#54 0x00005555557bbdfc in run_hook_with_args (nargs=2, args=0x7fffffffd260, funcall=0x55555570b130 <safe_run_hook_funcall>) at eval.c:2854
#55 0x0000555555711517 in safe_run_hooks_maybe_narrowed (hook=hook@entry=XIL(0xd260), w=<optimized out>) at keyboard.c:1929
#56 0x0000555555723f37 in command_loop_1 () at keyboard.c:1516
#57 0x00005555557bb657 in internal_condition_case (bfun=bfun@entry=0x555555723b00 <command_loop_1>, handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x55555570b260 <cmd_error>) at eval.c:1474
#58 0x00005555557094f6 in command_loop_2 (handlers=handlers@entry=XIL(0x90)) at keyboard.c:1131
#59 0x00005555557bb5ac in internal_catch (tag=tag@entry=XIL(0x10050), func=func@entry=0x5555557094d0 <command_loop_2>, arg=arg@entry=XIL(0x90)) at eval.c:1197
#60 0x0000555555709491 in command_loop () at keyboard.c:1109
#61 0x0000555555710fb2 in recursive_edit_1 () at keyboard.c:718
#62 0x0000555555711310 in Frecursive_edit () at keyboard.c:801
#63 0x00005555555adfa5 in main (argc=2, argv=0x7fffffffd7d8) at emacs.c:2529

Any idea what's going on and how I should debug this further?


Cheers

Re: Emacs segfaults when handling wrong_type_argument backtrace

[Eli Zaretskii]

> Date: Wed, 29 Mar 2023 23:54:19 +0200
> From: Jonas Jelten <jj@sft.lol>
> 
> Hi!
> 
> I'm using emacs-29 at ab4273056e0ab68a27fe807b16e2995bf84b72ec with Doom Emacs with on Gentoo.
> 
> configured with:
> ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --datarootdir=/usr/share --disable-silent-rules --docdir=/usr/share/doc/emacs-29.0.9999-r1 --htmldir=/usr/share/doc/emacs-29.0.9999-r1/html --libdir=/usr/lib64 --program-suffix=-emacs-29-vcs 
> --includedir=/usr/include/emacs-29-vcs --infodir=/usr/share/info/emacs-29-vcs --localstatedir=/var --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp --without-compress-install --without-hesiod --without-pop --with-file-notification=inotify --with-pdumper --enable-acl --with-dbus --with-modules --with-gameuser=:gamestat --with-libgmp --with-gpm --with-native-compilation=aot --with-json 
> --with-kerberos --with-kerberos5 --with-lcms2 --with-xml2 --with-mailutils --without-selinux --with-sqlite3 --with-gnutls --with-libsystemd --with-threads --without-tree-sitter --without-wide-int --with-sound=alsa --with-zlib --with-x --without-pgtk --without-ns --without-gconf --with-gsettings --with-toolkit-scroll-bars --with-xpm --with-xft --with-cairo --with-harfbuzz --without-libotf 
> --without-m17n-flt --with-x-toolkit=gtk3 --without-xwidgets --with-gif --with-jpeg --with-png --with-rsvg --with-tiff --with-webp --with-imagemagick --with-dumping=pdumper
> 
> Launch with GDB:
> gdb --args emacs --debug-init
> 
> = gdb>> source emacs/src/.gdbinit
> 
> 
> When yasnippet triggers a backtrace, Emacs crashes:
> 
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> 0x000055555579d2a4 in PSEUDOVECTORP (code=<optimized out>, a=<optimized out>) at data.c:495
> 495	DEFUN ("byte-code-function-p", Fbyte_code_function_p, Sbyte_code_function_p,
> 
> = gdb>> disassemble
> Dump of assembler code for function Fbyte_code_function_p:
>     0x000055555579d290 <+0>:	lea    edx,[rdi-0x5]
>     0x000055555579d293 <+3>:	xor    eax,eax
>     0x000055555579d295 <+5>:	and    edx,0x7
>     0x000055555579d298 <+8>:	jne    0x55555579d2be <Fbyte_code_function_p+46>
>     0x000055555579d29a <+10>:	movabs rdx,0x400000003f000000
> => 0x000055555579d2a4 <+20>:	and    rdx,QWORD PTR [rdi-0x5]
>     0x000055555579d2a8 <+24>:	movabs rcx,0x400000001e000000
>     0x000055555579d2b2 <+34>:	cmp    rdx,rcx
>     0x000055555579d2b5 <+37>:	mov    edx,0x30
>     0x000055555579d2ba <+42>:	cmove  rax,rdx
>     0x000055555579d2be <+46>:	ret
> End of assembler dump.

Please always report bugs, including crashes, using report-emacs-bug,
so that they get a bug ID and get recorded by our bug tracker.

CC'ing Andrea, who made a recent change in that area.

Re: Emacs segfaults when handling wrong_type_argument backtrace

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 29 Mar 2023 23:54:19 +0200
>> From: Jonas Jelten <jj@sft.lol>
>> 
>> Hi!
>> 
>> I'm using emacs-29 at ab4273056e0ab68a27fe807b16e2995bf84b72ec with Doom Emacs with on Gentoo.
>> 
>> configured with:
>> ./configure --prefix=/usr --build=x86_64-pc-linux-gnu
>> --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
>> --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
>> --localstatedir=/var/lib --datarootdir=/usr/share
>> --disable-silent-rules --docdir=/usr/share/doc/emacs-29.0.9999-r1
>> --htmldir=/usr/share/doc/emacs-29.0.9999-r1/html --libdir=/usr/lib64
>> --program-suffix=-emacs-29-vcs
>> --includedir=/usr/include/emacs-29-vcs
>> --infodir=/usr/share/info/emacs-29-vcs --localstatedir=/var
>> --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
>> --without-compress-install --without-hesiod --without-pop
>> --with-file-notification=inotify --with-pdumper --enable-acl
>> --with-dbus --with-modules --with-gameuser=:gamestat --with-libgmp
>> --with-gpm --with-native-compilation=aot --with-json
>> --with-kerberos --with-kerberos5 --with-lcms2 --with-xml2
>> --with-mailutils --without-selinux --with-sqlite3 --with-gnutls
>> --with-libsystemd --with-threads --without-tree-sitter
>> --without-wide-int --with-sound=alsa --with-zlib --with-x
>> --without-pgtk --without-ns --without-gconf --with-gsettings
>> --with-toolkit-scroll-bars --with-xpm --with-xft --with-cairo
>> --with-harfbuzz --without-libotf
>> --without-m17n-flt --with-x-toolkit=gtk3 --without-xwidgets
>> --with-gif --with-jpeg --with-png --with-rsvg --with-tiff
>> --with-webp --with-imagemagick --with-dumping=pdumper
>> 
>> Launch with GDB:
>> gdb --args emacs --debug-init
>> 
>> = gdb>> source emacs/src/.gdbinit
>> 
>> 
>> When yasnippet triggers a backtrace, Emacs crashes:
>> 
>> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
>> 0x000055555579d2a4 in PSEUDOVECTORP (code=<optimized out>, a=<optimized out>) at data.c:495
>> 495	DEFUN ("byte-code-function-p", Fbyte_code_function_p, Sbyte_code_function_p,
>> 
>> = gdb>> disassemble
>> Dump of assembler code for function Fbyte_code_function_p:
>>     0x000055555579d290 <+0>:	lea    edx,[rdi-0x5]
>>     0x000055555579d293 <+3>:	xor    eax,eax
>>     0x000055555579d295 <+5>:	and    edx,0x7
>>     0x000055555579d298 <+8>:	jne    0x55555579d2be <Fbyte_code_function_p+46>
>>     0x000055555579d29a <+10>:	movabs rdx,0x400000003f000000
>> => 0x000055555579d2a4 <+20>:	and    rdx,QWORD PTR [rdi-0x5]
>>     0x000055555579d2a8 <+24>:	movabs rcx,0x400000001e000000
>>     0x000055555579d2b2 <+34>:	cmp    rdx,rcx
>>     0x000055555579d2b5 <+37>:	mov    edx,0x30
>>     0x000055555579d2ba <+42>:	cmove  rax,rdx
>>     0x000055555579d2be <+46>:	ret
>> End of assembler dump.
>
> Please always report bugs, including crashes, using report-emacs-bug,
> so that they get a bug ID and get recorded by our bug tracker.
>
> CC'ing Andrea, who made a recent change in that area.

Thanks, I guess this should be fixed.

Jonas could you please try again after having cleaned the eln-cache
directory and report?

Eli if we want to avoid spurious bug reports due to stale eln-cache we
can also increment ABI_VERSION in comp.c.  Not sure is something we want
to do tho.  Please let me know if you think is appropriate in this case.

Thanks

  Andrea

Re: Emacs segfaults when handling wrong_type_argument backtrace

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Jonas Jelten <jj@sft.lol>, emacs-devel@gnu.org
> Date: Thu, 30 Mar 2023 09:36:25 +0000
> 
> Eli if we want to avoid spurious bug reports due to stale eln-cache we
> can also increment ABI_VERSION in comp.c.  Not sure is something we want
> to do tho.  Please let me know if you think is appropriate in this case.

I don't think we need to increment ABI_VERSION to avoid bug reports,
no.  Yes, that places additional burden on my and your shoulders
(perhaps mainly on yours), but bumping the ABI_VERSION has its own
downsides (e.g., it requires recompilation of all the preloaded
files), and I don't think this is justified.  People who track
development versions and use that for production sessions will have to
be prepared to clean up their eln-cache from time to time, when
changes like this one are made.

Re: Emacs segfaults when handling wrong_type_argument backtrace

[Jonas Jelten]

On 2023-03-30 12:30, Eli Zaretskii wrote:
>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: Jonas Jelten <jj@sft.lol>, emacs-devel@gnu.org
>> Date: Thu, 30 Mar 2023 09:36:25 +0000
>>
>> Eli if we want to avoid spurious bug reports due to stale eln-cache we
>> can also increment ABI_VERSION in comp.c.  Not sure is something we want
>> to do tho.  Please let me know if you think is appropriate in this case.
> 
> I don't think we need to increment ABI_VERSION to avoid bug reports,
> no.  Yes, that places additional burden on my and your shoulders
> (perhaps mainly on yours), but bumping the ABI_VERSION has its own
> downsides (e.g., it requires recompilation of all the preloaded
> files), and I don't think this is justified.  People who track
> development versions and use that for production sessions will have to
> be prepared to clean up their eln-cache from time to time, when
> changes like this one are made.
> 

After clearing the cache it seems to work, thanks, that was easy.
I assumed that changes in the abi would result in a version bump :)
Shouldn't recompilation of files happen in such a case rather than random crashes, though? Or ar there other, more complicated downsides?


Cheers
   -- Jonas

Re: Emacs segfaults when handling wrong_type_argument backtrace

[Andrea Corallo]

Jonas Jelten <jj@sft.lol> writes:

> On 2023-03-30 12:30, Eli Zaretskii wrote:
>>> From: Andrea Corallo <akrl@sdf.org>
>>> Cc: Jonas Jelten <jj@sft.lol>, emacs-devel@gnu.org
>>> Date: Thu, 30 Mar 2023 09:36:25 +0000
>>>
>>> Eli if we want to avoid spurious bug reports due to stale eln-cache we
>>> can also increment ABI_VERSION in comp.c.  Not sure is something we want
>>> to do tho.  Please let me know if you think is appropriate in this case.
>> I don't think we need to increment ABI_VERSION to avoid bug reports,
>> no.  Yes, that places additional burden on my and your shoulders
>> (perhaps mainly on yours), but bumping the ABI_VERSION has its own
>> downsides (e.g., it requires recompilation of all the preloaded
>> files), and I don't think this is justified.  People who track
>> development versions and use that for production sessions will have to
>> be prepared to clean up their eln-cache from time to time, when
>> changes like this one are made.
>> 
>
> After clearing the cache it seems to work, thanks, that was easy.
> I assumed that changes in the abi would result in a version bump :)

It results in Emacs changing the directory name of the eln under
eln-cache, this way Emacs would discard all the other elns and produce
new ones.

We usually do that when we change something low level in an incompatible
way in the eln format.  I agree with Eli we should not use that for
cases when a bug might have produced miscompiled elns.

BR

  Andrea

Re: Emacs segfaults when handling wrong_type_argument backtrace

[Jonas Jelten]

On 2023-03-30 20:51, Andrea Corallo wrote:
> Jonas Jelten <jj@sft.lol> writes:
>> After clearing the cache it seems to work, thanks, that was easy.
>> I assumed that changes in the abi would result in a version bump :)
> 
> It results in Emacs changing the directory name of the eln under
> eln-cache, this way Emacs would discard all the other elns and produce
> new ones.
> 
> We usually do that when we change something low level in an incompatible
> way in the eln format.  I agree with Eli we should not use that for
> cases when a bug might have produced miscompiled elns.
> 
> BR
> 
>    Andrea
> 

Ah I see, if the change was unintentional, ABI version bumps don't make sense, indeed.

Thanks for your awesome work on making the pig faster :)

   -- JJ

Re: Emacs segfaults when handling wrong_type_argument backtrace

[tomas]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

On Fri, Mar 31, 2023 at 09:01:04PM +0200, Jonas Jelten wrote:
> On 2023-03-30 20:51, Andrea Corallo wrote:
> > Jonas Jelten <jj@sft.lol> writes:
> > > After clearing the cache it seems to work, thanks, that was easy.
> > > I assumed that changes in the abi would result in a version bump :)
> > 
> > It results in Emacs changing the directory name of the eln under
> > eln-cache, this way Emacs would discard all the other elns and produce
> > new ones.

Just curious: what happens with the old directories?

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Emacs segfaults when handling wrong_type_argument backtrace

[Eli Zaretskii]

> Date: Sat, 1 Apr 2023 07:51:29 +0200
> From: <tomas@tuxteam.de>
> 
> On Fri, Mar 31, 2023 at 09:01:04PM +0200, Jonas Jelten wrote:
> > On 2023-03-30 20:51, Andrea Corallo wrote:
> > > Jonas Jelten <jj@sft.lol> writes:
> > > > After clearing the cache it seems to work, thanks, that was easy.
> > > > I assumed that changes in the abi would result in a version bump :)
> > > 
> > > It results in Emacs changing the directory name of the eln under
> > > eln-cache, this way Emacs would discard all the other elns and produce
> > > new ones.
> 
> Just curious: what happens with the old directories?

Nothing: they stay as they were.

Re: Emacs segfaults when handling wrong_type_argument backtrace

[tomas]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

On Sat, Apr 01, 2023 at 09:11:04AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 1 Apr 2023 07:51:29 +0200
> > From: <tomas@tuxteam.de>
> > 
> > On Fri, Mar 31, 2023 at 09:01:04PM +0200, Jonas Jelten wrote:
> > > On 2023-03-30 20:51, Andrea Corallo wrote:
> > > > Jonas Jelten <jj@sft.lol> writes:
> > > > > After clearing the cache it seems to work, thanks, that was easy.
> > > > > I assumed that changes in the abi would result in a version bump :)
> > > > 
> > > > It results in Emacs changing the directory name of the eln under
> > > > eln-cache, this way Emacs would discard all the other elns and produce
> > > > new ones.
> > 
> > Just curious: what happens with the old directories?
> 
> Nothing: they stay as they were.

Thanks
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]