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