bug#70760: 29.3.50; core dumps when copy in other apps

bug#70760: 29.3.50; core dumps when copy in other apps

[Kun Liu]

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

Emacs is running inside VirtualBox on Windows 11. It randomly crashes
when I do a copy from other apps running on the host, e.g., Chrome on
Windows 11.

(gdb) bt full
#0  raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:50
        set = {__val = {18446744067266837247, 0 <repeats 15 times>}}
        pid = <optimized out>
        tid = <optimized out>
#1  0x000055b069545cdd in terminate_due_to_signal (sig=sig@entry=11,
backtrace_limit=1774226416, backtrace_limit@entry=40) at emacs.c:464
#2  0x000055b06956a07f in handle_fatal_signal (sig=sig@entry=11) at
sysdep.c:1783
#3  0x000055b06956a0ac in deliver_thread_signal (sig=sig@entry=11,
handler=handler@entry=0x55b06956a071 <handle_fatal_signal>) at sysdep.c:1775
        old_errno = 11
#4  0x000055b06956a110 in deliver_fatal_thread_signal (sig=sig@entry=11) at
sysdep.c:1795
#5  0x000055b06956a1e4 in handle_sigsegv (sig=11, siginfo=0x55b069c08e30
<sigsegv_stack+64528>, arg=<optimized out>) at sysdep.c:1888
        fatal = <optimized out>
#6  0x00007f29a30f0140 in <signal handler called> () at
/lib/x86_64-linux-gnu/libpthread.so.0
#7  PSEUDOVECTOR_TYPE (v=0x2720200a65646f68) at lisp.h:1810
        size = <optimized out>
        base_depth = <optimized out>
        base_sp = 0
        buf =
"\260\036\252k\260U\000\000\373L\\i\260U\000\000\240D\000\000\000\000\000\000\064M\\i\260U\000\000\063\374\360q\260U\000\000\320\067Wi\260U\000\000\001\000\000\000\000"
#8  print_object (obj=obj@entry=0x2720200a65646f6d,
printcharfun=printcharfun@entry=0x30, escapeflag=escapeflag@entry=true) at
print.c:2518
        base_depth = <optimized out>
        base_sp = 0
        buf =
"\260\036\252k\260U\000\000\373L\\i\260U\000\000\240D\000\000\000\000\000\000\064M\\i\260U\000\000\063\374\360q\260U\000\000\320\067Wi\260U\000\000\001\000\000\000\000"
#9  0x000055b06960371f in print (obj=obj@entry=0x2720200a65646f6d,
printcharfun=0x30, escapeflag=escapeflag@entry=true) at print.c:1301
#10 0x000055b069603849 in Fprin1 (object=0x2720200a65646f6d,
printcharfun=printcharfun@entry=0x30, overrides=overrides@entry=0x0) at
print.c:776
        pc = {printcharfun = 0x30, old_printcharfun = 0x30, old_point = -1,
start_point = -1, old_point_byte = -1, start_point_byte = -1, specpdl_count
= {bytes = 224}}
#11 0x000055b069603f3e in print_error_message (data=<optimized out>,
data@entry=0x55b085976613, stream=stream@entry=0x30, context=<optimized
out>, caller=caller@entry=0x7fe0) at lisp.h:1172
        obj = <optimized out>
        li = {tortoise = 0x55b0859765f3, max = 2, n = 0, q = 1}
        sep = 0x55b0696ad6a0 ", "
        errname = 0x11f40
        errmsg = 0x55b06c78e6e4
        file_error = 0x0
        tail = 0x55b0859765e3
#12 0x000055b069548c3c in Fcommand_error_default_function
(data=0x55b085976613, context=0x7f299d1b3284, signal=0x7fe0) at lisp.h:1172
        sf = 0x55b06c11d3d0
        conditions = <optimized out>
        is_minibuffer_quit = 0
#13 0x000055b0695db11d in funcall_subr (subr=0x55b069b8bb20
<Scommand_error_default_function>, numargs=numargs@entry=3,
args=args@entry=0x7f299ca7b050)
at eval.c:3042
        argbuf = {0x0, 0x55b071ef0428, 0x0, 0x0, 0x0, 0x0, 0x10100728cd228,
0x60}
        a = <optimized out>
        fun = <optimized out>
#14 0x000055b06961fbd7 in exec_byte_code (fun=<optimized out>,
fun@entry=0x7f299d61918d,
args_template=<optimized out>, args_template@entry=771, nargs=<optimized
out>, nargs@entry=3, args=<optimized out>, args@entry=0x7ffc393a2e58) at
bytecode.c:809
        call_nargs = 3
        call_fun = <optimized out>
        template = <optimized out>
        val = <optimized out>
        call_args = 0x7f299ca7b050
        original_fun = 0x297933a03400
        bytecode = <optimized out>
        op = 3
        type = <optimized out>
        targets = {0x55b069621ca3 <exec_byte_code+11255>, 0x55b069621cbd
<exec_byte_code+11281>, 0x55b069621cf2 <exec_byte_code+11334>,
0x55b069621cf4 <exec_byte_code+11336>, 0x55b069621cf6
<exec_byte_code+11338>, 0x55b069621cbd <exec_byte_code+11281>,
0x55b069621cf8 <exec_byte_code+11340>, 0x55b069621d31
<exec_byte_code+11397>, 0x55b06961f27b <exec_byte_code+463>, 0x55b06961f2c4
<exec_byte_code+536>, 0x55b06961f2c6 <exec_byte_code+538>, 0x55b06961f2c8
<exec_byte_code+540>, 0x55b06961f2ca <exec_byte_code+542>, 0x55b06961f27b
<exec_byte_code+463>, 0x55b06961f2cc <exec_byte_code+544>, 0x55b06961f268
<exec_byte_code+444>, 0x55b06961f61e <exec_byte_code+1394>, 0x55b06961f67d
<exec_byte_code+1489>, 0x55b06961f67f <exec_byte_code+1491>, 0x55b06961f681
<exec_byte_code+1493>, 0x55b06961f683 <exec_byte_code+1495>, 0x55b06961f61e
<exec_byte_code+1394>, 0x55b06961f698 <exec_byte_code+1516>, 0x55b06961f685
<exec_byte_code+1497>, 0x55b06961f7ce <exec_byte_code+1826>, 0x55b06961f813
<exec_byte_code+1895>, 0x55b06961f815 <exec_byte_code+1897>, 0x55b06961f817
<exec_byte_code+1899>, 0x55b06961f819 <exec_byte_code+1901>, 0x55b06961f7ce
<exec_byte_code+1826>, 0x55b06961f7b1 <exec_byte_code+1797>, 0x55b06961f7bb
<exec_byte_code+1807>, 0x55b06961f838 <exec_byte_code+1932>, 0x55b06961f98b
<exec_byte_code+2271>, 0x55b06961f990 <exec_byte_code+2276>, 0x55b06961f995
<exec_byte_code+2281>, 0x55b06961f99a <exec_byte_code+2286>, 0x55b06961f838
<exec_byte_code+1932>, 0x55b06961f81b <exec_byte_code+1903>, 0x55b06961f825
<exec_byte_code+1913>, 0x55b06961fc10 <exec_byte_code+2916>, 0x55b06961fc5d
<exec_byte_code+2993>, 0x55b06961fc5f <exec_byte_code+2995>, 0x55b06961fc61
<exec_byte_code+2997>, 0x55b06961fc63 <exec_byte_code+2999>, 0x55b06961fc10
<exec_byte_code+2916>, 0x55b06961fbf3 <exec_byte_code+2887>, 0x55b06961fbfd
<exec_byte_code+2897>, 0x55b0696200ce <exec_byte_code+4130>, 0x55b06962006e
<exec_byte_code+4034>, 0x55b069620003 <exec_byte_code+3927>, 0x55b069621ca3
<exec_byte_code+11255>, 0x55b069621ca3 <exec_byte_code+11255>,
0x55b069621ca3 <exec_byte_code+11255>, 0x55b069621ca3
<exec_byte_code+11255>, 0x55b069621ca3 <exec_byte_code+11255>,
0x55b06962023a <exec_byte_code+4494>, 0x55b0696202e9 <exec_byte_code+4669>,
0x55b069620383 <exec_byte_code+4823>, 0x55b0696203ca <exec_byte_code+4894>,
0x55b069620411 <exec_byte_code+4965>, 0x55b06961f40d <exec_byte_code+865>,
0x55b06961f5a3 <exec_byte_code+1271>, 0x55b06962045c <exec_byte_code+5040>,
0x55b06961f3cc <exec_byte_code+800>, 0x55b06961f5dd <exec_byte_code+1329>,
0x55b069620496 <exec_byte_code+5098>, 0x55b0696204d0 <exec_byte_code+5156>,
0x55b0696204fc <exec_byte_code+5200>, 0x55b069620536 <exec_byte_code+5258>,
0x55b06962056f <exec_byte_code+5315>, 0x55b0696205ed <exec_byte_code+5441>,
0x55b069620619 <exec_byte_code+5485>, 0x55b0696206f6 <exec_byte_code+5706>,
0x55b0696207d5 <exec_byte_code+5929>, 0x55b069620801 <exec_byte_code+5973>,
0x55b06962082d <exec_byte_code+6017>, 0x55b069620867 <exec_byte_code+6075>,
0x55b0696208a1 <exec_byte_code+6133>, 0x55b0696208db <exec_byte_code+6191>,
0x55b06962091b <exec_byte_code+6255>, 0x55b069620951 <exec_byte_code+6309>,
0x55b069620987 <exec_byte_code+6363>, 0x55b0696209fe <exec_byte_code+6482>,
0x55b069620a55 <exec_byte_code+6569>, 0x55b069620aac <exec_byte_code+6656>,
0x55b069620b17 <exec_byte_code+6763>, 0x55b069620b8a <exec_byte_code+6878>,
0x55b069620bfd <exec_byte_code+6993>, 0x55b069620c70 <exec_byte_code+7108>,
0x55b069620ce3 <exec_byte_code+7223>, 0x55b069620d6d <exec_byte_code+7361>,
0x55b069620dce <exec_byte_code+7458>, 0x55b069620e58 <exec_byte_code+7596>,
0x55b069620ec3 <exec_byte_code+7703>, 0x55b069620f2e <exec_byte_code+7810>,
0x55b0696210cf <exec_byte_code+8227>, 0x55b06961fefe <exec_byte_code+3666>,
0x55b069621115 <exec_byte_code+8297>, 0x55b069621141 <exec_byte_code+8341>,
0x55b0696211b3 <exec_byte_code+8455>, 0x55b0696211f9 <exec_byte_code+8525>,
0x55b06962123f <exec_byte_code+8595>, 0x55b06962126b <exec_byte_code+8639>,
0x55b069621299 <exec_byte_code+8685>, 0x55b0696212c7 <exec_byte_code+8731>,
0x55b0696212fd <exec_byte_code+8785>, 0x55b069621ca3
<exec_byte_code+11255>, 0x55b06962132e <exec_byte_code+8834>,
0x55b06962135c <exec_byte_code+8880>, 0x55b06962138a <exec_byte_code+8926>,
0x55b0696213b8 <exec_byte_code+8972>, 0x55b0696213e6 <exec_byte_code+9018>,
0x55b069621414 <exec_byte_code+9064>, 0x55b06961fefe <exec_byte_code+3666>,
0x55b069621ca3 <exec_byte_code+11255>, 0x55b069621440
<exec_byte_code+9108>, 0x55b069621481 <exec_byte_code+9173>, 0x55b0696214ad
<exec_byte_code+9217>, 0x55b0696214d9 <exec_byte_code+9261>, 0x55b069621513
<exec_byte_code+9319>, 0x55b06962154d <exec_byte_code+9377>, 0x55b069621579
<exec_byte_code+9421>, 0x55b0696215a5 <exec_byte_code+9465>, 0x55b0696215df
<exec_byte_code+9523>, 0x55b069621619 <exec_byte_code+9581>, 0x55b069621653
<exec_byte_code+9639>, 0x55b069621681 <exec_byte_code+9685>, 0x55b069621ca3
<exec_byte_code+11255>, 0x55b06961fe9a <exec_byte_code+3566>,
0x55b06961fc65 <exec_byte_code+3001>, 0x55b06961f38a <exec_byte_code+734>,
0x55b06961fce8 <exec_byte_code+3132>, 0x55b06961fd26 <exec_byte_code+3194>,
0x55b06961fd64 <exec_byte_code+3256>, 0x55b06961fda6 <exec_byte_code+3322>,
0x55b06961fe78 <exec_byte_code+3532>, 0x55b06961f785 <exec_byte_code+1753>,
0x55b06961fedc <exec_byte_code+3632>, 0x55b06961ff2f <exec_byte_code+3715>,
0x55b06961ff91 <exec_byte_code+3813>, 0x55b06961ffc2 <exec_byte_code+3862>,
0x55b0696200fe <exec_byte_code+4178>, 0x55b069620151 <exec_byte_code+4261>,
0x55b069620191 <exec_byte_code+4325>, 0x55b0696201dd <exec_byte_code+4401>,
0x55b069621ca3 <exec_byte_code+11255>, 0x55b0696216ad
<exec_byte_code+9729>, 0x55b0696216ed <exec_byte_code+9793>, 0x55b069621719
<exec_byte_code+9837>, 0x55b069621745 <exec_byte_code+9881>, 0x55b069621771
<exec_byte_code+9925>, 0x55b06962179d <exec_byte_code+9969>, 0x55b0696217d7
<exec_byte_code+10027>, 0x55b069621811 <exec_byte_code+10085>,
0x55b06962184b <exec_byte_code+10143>, 0x55b069621885
<exec_byte_code+10201>, 0x55b069621942 <exec_byte_code+10390>,
0x55b06962197c <exec_byte_code+10448>, 0x55b0696219b6
<exec_byte_code+10506>, 0x55b0696219e2 <exec_byte_code+10550>,
0x55b069621a4e <exec_byte_code+10658>, 0x55b069621aba
<exec_byte_code+10766>, 0x55b069621af8 <exec_byte_code+10828>,
0x55b069621b36 <exec_byte_code+10890>, 0x55b069620fd0
<exec_byte_code+7972>, 0x55b069621061 <exec_byte_code+8117>, 0x55b069621b6c
<exec_byte_code+10944>, 0x55b069621c15 <exec_byte_code+11113>,
0x55b069621ca3 <exec_byte_code+11255>, 0x55b069621ca3
<exec_byte_code+11255>, 0x55b069621ca3 <exec_byte_code+11255>,
0x55b069621ca3 <exec_byte_code+11255>, 0x55b069621ca3
<exec_byte_code+11255>, 0x55b069621ca3 <exec_byte_code+11255>,
0x55b0696205ac <exec_byte_code+5376>, 0x55b0696209bd <exec_byte_code+6417>,
0x55b069621172 <exec_byte_code+8390>, 0x55b069621d73
<exec_byte_code+11463>, 0x55b069621db4 <exec_byte_code+11528>,
0x55b069621ca3 <exec_byte_code+11255>, 0x55b069621ca3
<exec_byte_code+11255>, 0x55b069621e00 <exec_byte_code+11604>,
0x55b069621e4c <exec_byte_code+11680>, 0x55b069621ca3
<exec_byte_code+11255>, 0x55b069621ca3 <exec_byte_code+11255>,
0x55b069621ca3 <exec_byte_code+11255>, 0x55b069621ca3
<exec_byte_code+11255>, 0x55b069621ca3 <exec_byte_code+11255>,
0x55b069621ca3 <exec_byte_code+11255>, 0x55b069621ca3
<exec_byte_code+11255>, 0x55b069621ca3 <exec_byte_code+11255>,
0x55b069622044 <exec_byte_code+12184> <repeats 64 times>}
        quitcounter = 1 '\001'
        bc = 0x55b069b800f0 <main_thread+496>
        top = 0x7f299ca7b048
        pc = 0x7f299da7f001 "\210\002:\205:"
        bytestr = <optimized out>
        vector = <optimized out>
        maxdepth = <optimized out>
        const_length = <optimized out>
        bytestr_length = <optimized out>
        vectorp = 0x7f299d6191d0
        max_stack = <optimized out>
        frame_base = <optimized out>
        fp = <optimized out>
        bytestr_data = 0x7f299da7effc "\300\003\003\003#\210\002:\205:"
        rest = <optimized out>
        mandatory = <optimized out>
        nonrest = <optimized out>
        pushedargs = <optimized out>
        result = <optimized out>
#15 0x000055b0695da5f6 in fetch_and_exec_byte_code
(fun=fun@entry=0x7f299d61918d,
args_template=args_template@entry=771, nargs=nargs@entry=3,
args=args@entry=0x7ffc393a2e58)
at eval.c:3085
#16 0x000055b0695dd530 in funcall_lambda (fun=0x7f299d61918d,
nargs=nargs@entry=3, arg_vector=arg_vector@entry=0x7ffc393a2e58) at
eval.c:3157
        val = <optimized out>
        syms_left = 0xc0e
        next = <optimized out>
        lexenv = <optimized out>
        i = <optimized out>
        optional = <optimized out>
        rest = <optimized out>
        previous_rest = <optimized out>
#17 0x000055b0695dde93 in funcall_general (fun=<optimized out>,
numargs=numargs@entry=3, args=args@entry=0x7ffc393a2e58) at eval.c:2949
        original_fun = 0x297933a02f38
#18 0x000055b0695d8d28 in Ffuncall (nargs=nargs@entry=4,
args=args@entry=0x7ffc393a2e50)
at eval.c:2999
        val = <optimized out>
#19 0x000055b06954e55e in call3 (arg3=0x7fe0, arg2=<optimized out>,
arg1=0x55b085976613, fn=<optimized out>) at lisp.h:3262
#20 cmd_error_internal (data=data@entry=0x55b085976613,
context=context@entry=0x7ffc393a2e90 "") at keyboard.c:1013
#21 0x000055b06954e67c in cmd_error (data=0x55b085976613) at keyboard.c:981
        old_level = 0x0
        old_length = 0x0
        conditions = <optimized out>
        macroerror =
"\000L\000\000\000\000\000\000\260Q}\003\000\000\000\000UYmm\260U\000\000\000\000\000\000\000\000\000\000\220\207\000\000\000\000\000\000@
)\000\000\000\000\000\000D\251"
#22 0x000055b0695d77a8 in internal_condition_case
(bfun=bfun@entry=0x55b06955d740
<command_loop_1>, handlers=handlers@entry=0x90, hfun=hfun@entry=0x55b06954e57b
<cmd_error>) at eval.c:1470
        val = <optimized out>
        c = 0x55b06ba8ff50
#23 0x000055b069547832 in command_loop_2 (handlers=handlers@entry=0x90) at
keyboard.c:1133
        val = <optimized out>
#24 0x000055b0695d772b in internal_catch (tag=tag@entry=0x10080,
func=func@entry=0x55b069547818 <command_loop_2>, arg=arg@entry=0x90) at
eval.c:1197
        val = <optimized out>
        c = 0x55b06ba8fe10
#25 0x000055b0695477f5 in command_loop () at lisp.h:1172
#26 0x000055b06954e122 in recursive_edit_1 () at keyboard.c:720
        val = <optimized out>
#27 0x000055b06954e4b7 in Frecursive_edit () at keyboard.c:803
        buffer = <optimized out>
#28 0x000055b069546ee4 in main (argc=1, argv=0x7ffc393a3148) at emacs.c:2521
        stack_bottom_variable = 0x55b06969be95 <__libc_csu_init+69>
        no_loadup = false
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x0
        original_pwd = <optimized out>
        dump_mode = <optimized out>
        skip_args = 0
        temacs = 0x0
        attempt_load_pdump = <optimized out>
        only_version = false
        rlim = {rlim_cur = 10022912, rlim_max = 18446744073709551615}
        lc_all = <optimized out>
        sockfd = -1
        module_assertions = <optimized out>


In GNU Emacs 29.3.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.24, cairo version 1.16.0) of 2024-05-03 built on debian
Repository revision: b392169e541a29178d7ae20f329d48b3d2bd78cf
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Configured using:
 'configure --with-native-compilation --with-tree-sitter 'CFLAGS=-ggdb
 -Og''

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBOTF LIBSELINUX LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Shell

Minor modes in effect:
  global-flycheck-mode: t
  server-mode: t
  global-diff-hl-mode: t
  engine-mode: t
  org-super-agenda-mode: t
  override-global-mode: t
  corfu-history-mode: t
  global-corfu-mode: t
  corfu-mode: t
  pdf-occur-global-minor-mode: t
  cscope-minor-mode: t
  shell-dirtrack-mode: t
  winner-mode: t
  desktop-save-mode: t
  icomplete-mode: t
  global-org-modern-mode: t
  comint-fontify-input-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tab-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  column-number-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/kun/.emacs.d/elpa/notmuch-20240406.1803/notmuch-message hides
/usr/local/share/emacs/site-lisp/notmuch-message
/home/kun/.emacs.d/elpa/notmuch-20240406.1803/notmuch-draft hides
/usr/local/share/emacs/site-lisp/notmuch-draft
/home/kun/.emacs.d/elpa/notmuch-20240406.1803/notmuch-wash hides
/usr/local/share/emacs/site-lisp/notmuch-wash
/home/kun/.emacs.d/elpa/notmuch-20240406.1803/notmuch-mua hides
/usr/local/share/emacs/site-lisp/notmuch-mua
/home/kun/.emacs.d/elpa/notmuch-20240406.1803/notmuch-jump hides
/usr/local/share/emacs/site-lisp/notmuch-jump
/home/kun/.emacs.d/elpa/notmuch-20240406.1803/notmuch-address hides
/usr/local/share/emacs/site-lisp/notmuch-address
/home/kun/.emacs.d/elpa/notmuch-20240406.1803/notmuch-show hides
/usr/local/share/emacs/site-lisp/notmuch-show
/home/kun/.emacs.d/elpa/notmuch-20240406.1803/notmuch-tree hides
/usr/local/share/emacs/site-lisp/notmuch-tree
/home/kun/.emacs.d/elpa/notmuch-20240406.1803/notmuch-maildir-fcc hides
/usr/local/share/emacs/site-lisp/notmuch-maildir-fcc
/home/kun/.emacs.d/elpa/notmuch-20240406.1803/notmuch-crypto hides
/usr/local/share/emacs/site-lisp/notmuch-crypto
/home/kun/.emacs.d/elpa/notmuch-20240406.1803/notmuch-query hides
/usr/local/share/emacs/site-lisp/notmuch-query
/home/kun/.emacs.d/elpa/notmuch-20240406.1803/notmuch-tag hides
/usr/local/share/emacs/site-lisp/notmuch-tag
/home/kun/.emacs.d/elpa/notmuch-20240406.1803/notmuch hides
/usr/local/share/emacs/site-lisp/notmuch
/home/kun/.emacs.d/elpa/notmuch-20240406.1803/notmuch-compat hides
/usr/local/share/emacs/site-lisp/notmuch-compat
/home/kun/.emacs.d/elpa/notmuch-20240406.1803/notmuch-company hides
/usr/local/share/emacs/site-lisp/notmuch-company
/home/kun/.emacs.d/elpa/notmuch-20240406.1803/notmuch-hello hides
/usr/local/share/emacs/site-lisp/notmuch-hello
/home/kun/.emacs.d/elpa/notmuch-20240406.1803/notmuch-parser hides
/usr/local/share/emacs/site-lisp/notmuch-parser
/home/kun/.emacs.d/elpa/notmuch-20240406.1803/notmuch-lib hides
/usr/local/share/emacs/site-lisp/notmuch-lib
/home/kun/.emacs.d/elpa/notmuch-20240406.1803/coolj hides
/usr/local/share/emacs/site-lisp/coolj
/home/kun/.emacs.d/elpa/notmuch-20240406.1803/notmuch-print hides
/usr/local/share/emacs/site-lisp/notmuch-print
/home/kun/.emacs.d/elpa/transient-20240421.1737/transient hides
/usr/local/share/emacs/29.3.50/lisp/transient
/home/kun/.emacs.d/elpa/org-9.6.28/ob-fortran hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-fortran
/home/kun/.emacs.d/elpa/org-9.6.28/org-timer hides
/usr/local/share/emacs/29.3.50/lisp/org/org-timer
/home/kun/.emacs.d/elpa/org-9.6.28/org-src hides
/usr/local/share/emacs/29.3.50/lisp/org/org-src
/home/kun/.emacs.d/elpa/org-9.6.28/ob-plantuml hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-plantuml
/home/kun/.emacs.d/elpa/org-9.6.28/org-refile hides
/usr/local/share/emacs/29.3.50/lisp/org/org-refile
/home/kun/.emacs.d/elpa/org-9.6.28/ob-scheme hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-scheme
/home/kun/.emacs.d/elpa/org-9.6.28/org-persist hides
/usr/local/share/emacs/29.3.50/lisp/org/org-persist
/home/kun/.emacs.d/elpa/org-9.6.28/ob-css hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-css
/home/kun/.emacs.d/elpa/org-9.6.28/ob-dot hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-dot
/home/kun/.emacs.d/elpa/org-9.6.28/org-entities hides
/usr/local/share/emacs/29.3.50/lisp/org/org-entities
/home/kun/.emacs.d/elpa/org-9.6.28/ob-maxima hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-maxima
/home/kun/.emacs.d/elpa/org-9.6.28/ob-perl hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-perl
/home/kun/.emacs.d/elpa/org-9.6.28/ol-doi hides
/usr/local/share/emacs/29.3.50/lisp/org/ol-doi
/home/kun/.emacs.d/elpa/org-9.6.28/ob-python hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-python
/home/kun/.emacs.d/elpa/org-9.6.28/org-habit hides
/usr/local/share/emacs/29.3.50/lisp/org/org-habit
/home/kun/.emacs.d/elpa/org-9.6.28/ob-eval hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-eval
/home/kun/.emacs.d/elpa/org-9.6.28/org-macro hides
/usr/local/share/emacs/29.3.50/lisp/org/org-macro
/home/kun/.emacs.d/elpa/org-9.6.28/ob-julia hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-julia
/home/kun/.emacs.d/elpa/org-9.6.28/ox-man hides
/usr/local/share/emacs/29.3.50/lisp/org/ox-man
/home/kun/.emacs.d/elpa/org-9.6.28/ob-lob hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-lob
/home/kun/.emacs.d/elpa/org-9.6.28/oc-bibtex hides
/usr/local/share/emacs/29.3.50/lisp/org/oc-bibtex
/home/kun/.emacs.d/elpa/org-9.6.28/ob-sass hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-sass
/home/kun/.emacs.d/elpa/org-9.6.28/ox hides
/usr/local/share/emacs/29.3.50/lisp/org/ox
/home/kun/.emacs.d/elpa/org-9.6.28/org-table hides
/usr/local/share/emacs/29.3.50/lisp/org/org-table
/home/kun/.emacs.d/elpa/org-9.6.28/oc-natbib hides
/usr/local/share/emacs/29.3.50/lisp/org/oc-natbib
/home/kun/.emacs.d/elpa/org-9.6.28/ob-C hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-C
/home/kun/.emacs.d/elpa/org-9.6.28/ob-java hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-java
/home/kun/.emacs.d/elpa/org-9.6.28/org-mouse hides
/usr/local/share/emacs/29.3.50/lisp/org/org-mouse
/home/kun/.emacs.d/elpa/org-9.6.28/ob hides
/usr/local/share/emacs/29.3.50/lisp/org/ob
/home/kun/.emacs.d/elpa/org-9.6.28/org-cycle hides
/usr/local/share/emacs/29.3.50/lisp/org/org-cycle
/home/kun/.emacs.d/elpa/org-9.6.28/ob-screen hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-screen
/home/kun/.emacs.d/elpa/org-9.6.28/ox-icalendar hides
/usr/local/share/emacs/29.3.50/lisp/org/ox-icalendar
/home/kun/.emacs.d/elpa/org-9.6.28/org-capture hides
/usr/local/share/emacs/29.3.50/lisp/org/org-capture
/home/kun/.emacs.d/elpa/org-9.6.28/ox-texinfo hides
/usr/local/share/emacs/29.3.50/lisp/org/ox-texinfo
/home/kun/.emacs.d/elpa/org-9.6.28/ob-ocaml hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-ocaml
/home/kun/.emacs.d/elpa/org-9.6.28/ob-table hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-table
/home/kun/.emacs.d/elpa/org-9.6.28/ox-beamer hides
/usr/local/share/emacs/29.3.50/lisp/org/ox-beamer
/home/kun/.emacs.d/elpa/org-9.6.28/ol-info hides
/usr/local/share/emacs/29.3.50/lisp/org/ol-info
/home/kun/.emacs.d/elpa/org-9.6.28/org-attach-git hides
/usr/local/share/emacs/29.3.50/lisp/org/org-attach-git
/home/kun/.emacs.d/elpa/org-9.6.28/org-version hides
/usr/local/share/emacs/29.3.50/lisp/org/org-version
/home/kun/.emacs.d/elpa/org-9.6.28/org-footnote hides
/usr/local/share/emacs/29.3.50/lisp/org/org-footnote
/home/kun/.emacs.d/elpa/org-9.6.28/ob-ref hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-ref
/home/kun/.emacs.d/elpa/org-9.6.28/ob-eshell hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-eshell
/home/kun/.emacs.d/elpa/org-9.6.28/ol-eshell hides
/usr/local/share/emacs/29.3.50/lisp/org/ol-eshell
/home/kun/.emacs.d/elpa/org-9.6.28/org-protocol hides
/usr/local/share/emacs/29.3.50/lisp/org/org-protocol
/home/kun/.emacs.d/elpa/org-9.6.28/ob-groovy hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-groovy
/home/kun/.emacs.d/elpa/org-9.6.28/org-plot hides
/usr/local/share/emacs/29.3.50/lisp/org/org-plot
/home/kun/.emacs.d/elpa/org-9.6.28/ob-ditaa hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-ditaa
/home/kun/.emacs.d/elpa/org-9.6.28/ob-sqlite hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-sqlite
/home/kun/.emacs.d/elpa/org-9.6.28/ob-shell hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-shell
/home/kun/.emacs.d/elpa/org-9.6.28/ox-md hides
/usr/local/share/emacs/29.3.50/lisp/org/ox-md
/home/kun/.emacs.d/elpa/org-9.6.28/org-inlinetask hides
/usr/local/share/emacs/29.3.50/lisp/org/org-inlinetask
/home/kun/.emacs.d/elpa/org-9.6.28/org hides
/usr/local/share/emacs/29.3.50/lisp/org/org
/home/kun/.emacs.d/elpa/org-9.6.28/ol-man hides
/usr/local/share/emacs/29.3.50/lisp/org/ol-man
/home/kun/.emacs.d/elpa/org-9.6.28/org-compat hides
/usr/local/share/emacs/29.3.50/lisp/org/org-compat
/home/kun/.emacs.d/elpa/org-9.6.28/ol-w3m hides
/usr/local/share/emacs/29.3.50/lisp/org/ol-w3m
/home/kun/.emacs.d/elpa/org-9.6.28/ol-docview hides
/usr/local/share/emacs/29.3.50/lisp/org/ol-docview
/home/kun/.emacs.d/elpa/org-9.6.28/ob-latex hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-latex
/home/kun/.emacs.d/elpa/org-9.6.28/ox-odt hides
/usr/local/share/emacs/29.3.50/lisp/org/ox-odt
/home/kun/.emacs.d/elpa/org-9.6.28/ob-haskell hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-haskell
/home/kun/.emacs.d/elpa/org-9.6.28/org-agenda hides
/usr/local/share/emacs/29.3.50/lisp/org/org-agenda
/home/kun/.emacs.d/elpa/org-9.6.28/org-datetree hides
/usr/local/share/emacs/29.3.50/lisp/org/org-datetree
/home/kun/.emacs.d/elpa/org-9.6.28/org-keys hides
/usr/local/share/emacs/29.3.50/lisp/org/org-keys
/home/kun/.emacs.d/elpa/org-9.6.28/ob-comint hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-comint
/home/kun/.emacs.d/elpa/org-9.6.28/org-num hides
/usr/local/share/emacs/29.3.50/lisp/org/org-num
/home/kun/.emacs.d/elpa/org-9.6.28/ob-matlab hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-matlab
/home/kun/.emacs.d/elpa/org-9.6.28/ob-js hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-js
/home/kun/.emacs.d/elpa/org-9.6.28/ol-eww hides
/usr/local/share/emacs/29.3.50/lisp/org/ol-eww
/home/kun/.emacs.d/elpa/org-9.6.28/org-goto hides
/usr/local/share/emacs/29.3.50/lisp/org/org-goto
/home/kun/.emacs.d/elpa/org-9.6.28/ob-processing hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-processing
/home/kun/.emacs.d/elpa/org-9.6.28/org-attach hides
/usr/local/share/emacs/29.3.50/lisp/org/org-attach
/home/kun/.emacs.d/elpa/org-9.6.28/ob-exp hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-exp
/home/kun/.emacs.d/elpa/org-9.6.28/org-mobile hides
/usr/local/share/emacs/29.3.50/lisp/org/org-mobile
/home/kun/.emacs.d/elpa/org-9.6.28/ox-publish hides
/usr/local/share/emacs/29.3.50/lisp/org/ox-publish
/home/kun/.emacs.d/elpa/org-9.6.28/oc-csl hides
/usr/local/share/emacs/29.3.50/lisp/org/oc-csl
/home/kun/.emacs.d/elpa/org-9.6.28/org-fold-core hides
/usr/local/share/emacs/29.3.50/lisp/org/org-fold-core
/home/kun/.emacs.d/elpa/org-9.6.28/oc hides
/usr/local/share/emacs/29.3.50/lisp/org/oc
/home/kun/.emacs.d/elpa/org-9.6.28/org-faces hides
/usr/local/share/emacs/29.3.50/lisp/org/org-faces
/home/kun/.emacs.d/elpa/org-9.6.28/ol-mhe hides
/usr/local/share/emacs/29.3.50/lisp/org/ol-mhe
/home/kun/.emacs.d/elpa/org-9.6.28/ob-lua hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-lua
/home/kun/.emacs.d/elpa/org-9.6.28/org-feed hides
/usr/local/share/emacs/29.3.50/lisp/org/org-feed
/home/kun/.emacs.d/elpa/org-9.6.28/oc-basic hides
/usr/local/share/emacs/29.3.50/lisp/org/oc-basic
/home/kun/.emacs.d/elpa/org-9.6.28/ob-emacs-lisp hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-emacs-lisp
/home/kun/.emacs.d/elpa/org-9.6.28/org-clock hides
/usr/local/share/emacs/29.3.50/lisp/org/org-clock
/home/kun/.emacs.d/elpa/org-9.6.28/org-list hides
/usr/local/share/emacs/29.3.50/lisp/org/org-list
/home/kun/.emacs.d/elpa/org-9.6.28/ol-rmail hides
/usr/local/share/emacs/29.3.50/lisp/org/ol-rmail
/home/kun/.emacs.d/elpa/org-9.6.28/ob-R hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-R
/home/kun/.emacs.d/elpa/org-9.6.28/ob-lisp hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-lisp
/home/kun/.emacs.d/elpa/org-9.6.28/ob-sed hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-sed
/home/kun/.emacs.d/elpa/org-9.6.28/ox-html hides
/usr/local/share/emacs/29.3.50/lisp/org/ox-html
/home/kun/.emacs.d/elpa/org-9.6.28/org-colview hides
/usr/local/share/emacs/29.3.50/lisp/org/org-colview
/home/kun/.emacs.d/elpa/org-9.6.28/ob-forth hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-forth
/home/kun/.emacs.d/elpa/org-9.6.28/org-archive hides
/usr/local/share/emacs/29.3.50/lisp/org/org-archive
/home/kun/.emacs.d/elpa/org-9.6.28/ox-org hides
/usr/local/share/emacs/29.3.50/lisp/org/ox-org
/home/kun/.emacs.d/elpa/org-9.6.28/org-element hides
/usr/local/share/emacs/29.3.50/lisp/org/org-element
/home/kun/.emacs.d/elpa/org-9.6.28/ol-gnus hides
/usr/local/share/emacs/29.3.50/lisp/org/ol-gnus
/home/kun/.emacs.d/elpa/org-9.6.28/ob-gnuplot hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-gnuplot
/home/kun/.emacs.d/elpa/org-9.6.28/org-macs hides
/usr/local/share/emacs/29.3.50/lisp/org/org-macs
/home/kun/.emacs.d/elpa/org-9.6.28/oc-biblatex hides
/usr/local/share/emacs/29.3.50/lisp/org/oc-biblatex
/home/kun/.emacs.d/elpa/org-9.6.28/org-id hides
/usr/local/share/emacs/29.3.50/lisp/org/org-id
/home/kun/.emacs.d/elpa/org-9.6.28/ol-irc hides
/usr/local/share/emacs/29.3.50/lisp/org/ol-irc
/home/kun/.emacs.d/elpa/org-9.6.28/ob-sql hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-sql
/home/kun/.emacs.d/elpa/org-9.6.28/ox-ascii hides
/usr/local/share/emacs/29.3.50/lisp/org/ox-ascii
/home/kun/.emacs.d/elpa/org-9.6.28/ob-ruby hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-ruby
/home/kun/.emacs.d/elpa/org-9.6.28/ob-calc hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-calc
/home/kun/.emacs.d/elpa/org-9.6.28/ob-clojure hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-clojure
/home/kun/.emacs.d/elpa/org-9.6.28/org-duration hides
/usr/local/share/emacs/29.3.50/lisp/org/org-duration
/home/kun/.emacs.d/elpa/org-9.6.28/org-pcomplete hides
/usr/local/share/emacs/29.3.50/lisp/org/org-pcomplete
/home/kun/.emacs.d/elpa/org-9.6.28/ox-koma-letter hides
/usr/local/share/emacs/29.3.50/lisp/org/ox-koma-letter
/home/kun/.emacs.d/elpa/org-9.6.28/org-ctags hides
/usr/local/share/emacs/29.3.50/lisp/org/org-ctags
/home/kun/.emacs.d/elpa/org-9.6.28/ox-latex hides
/usr/local/share/emacs/29.3.50/lisp/org/ox-latex
/home/kun/.emacs.d/elpa/org-9.6.28/ob-core hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-core
/home/kun/.emacs.d/elpa/org-9.6.28/ob-org hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-org
/home/kun/.emacs.d/elpa/org-9.6.28/org-tempo hides
/usr/local/share/emacs/29.3.50/lisp/org/org-tempo
/home/kun/.emacs.d/elpa/org-9.6.28/org-fold hides
/usr/local/share/emacs/29.3.50/lisp/org/org-fold
/home/kun/.emacs.d/elpa/org-9.6.28/ol-bibtex hides
/usr/local/share/emacs/29.3.50/lisp/org/ol-bibtex
/home/kun/.emacs.d/elpa/org-9.6.28/ob-lilypond hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-lilypond
/home/kun/.emacs.d/elpa/org-9.6.28/org-loaddefs hides
/usr/local/share/emacs/29.3.50/lisp/org/org-loaddefs
/home/kun/.emacs.d/elpa/org-9.6.28/org-lint hides
/usr/local/share/emacs/29.3.50/lisp/org/org-lint
/home/kun/.emacs.d/elpa/org-9.6.28/ob-tangle hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-tangle
/home/kun/.emacs.d/elpa/org-9.6.28/ol-bbdb hides
/usr/local/share/emacs/29.3.50/lisp/org/ol-bbdb
/home/kun/.emacs.d/elpa/org-9.6.28/ob-octave hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-octave
/home/kun/.emacs.d/elpa/org-9.6.28/ol hides
/usr/local/share/emacs/29.3.50/lisp/org/ol
/home/kun/.emacs.d/elpa/org-9.6.28/ob-awk hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-awk
/home/kun/.emacs.d/elpa/org-9.6.28/ob-makefile hides
/usr/local/share/emacs/29.3.50/lisp/org/ob-makefile
/home/kun/.emacs.d/elpa/org-9.6.28/org-indent hides
/usr/local/share/emacs/29.3.50/lisp/org/org-indent
/home/kun/.emacs.d/elpa/org-9.6.28/org-crypt hides
/usr/local/share/emacs/29.3.50/lisp/org/org-crypt

Features:
(shadow sort mail-extr emacsbug mule-util cape org-eldoc oc-basic ol-eww
eww url-queue mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect
gnus-art mm-uu mml2015 gnus-sum shr pixel-fill kinsoku url-file svg dom
gnus-group gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap
nnmail mail-source utf7 nnoo gnus-spec gnus-int gnus-range gnus-win gnus
nnheader range ol-docview doc-view filenotify ol-bibtex bibtex ol-bbdb
ol-w3m ol-doi org-link-doi misearch multi-isearch counsel xref swiper
ivy delsel ivy-faces ivy-overlay colir color sh-script smie executable
origami origami-parsers cl flycheck ob-sql ob-calc calc-store calc-trail
calc-ext calc calc-loaddefs rect calc-macs ob-python
python-el-fgallina-expansions python project treesit ob-ditaa
ob-plantuml zenburn-theme server diff-hl face-remap vc-hg vc-git
log-view pcvs-util vc-dir ewoc vc vc-dispatcher engine-mode
org-super-agenda ts comp comp-cstr warnings ht inline s dash org-habit
org-agenda expand-region text-mode-expansions the-org-mode-expansions
org-element org-persist xdg org-id org-refile avl-tree generator
er-basic-expansions expand-region-core expand-region-custom edmacro
kmacro use-package-bind-key bind-key corfu-history corfu
use-package-core avy notmuch notmuch-tree notmuch-jump notmuch-hello
notmuch-show notmuch-print notmuch-crypto notmuch-mua notmuch-message
notmuch-draft notmuch-maildir-fcc notmuch-address notmuch-company
notmuch-parser notmuch-wash diff-mode coolj goto-addr thingatpt
icalendar diary-lib diary-loaddefs notmuch-tag crm notmuch-lib
notmuch-version notmuch-compat hl-line message sendmail yank-media
rfc822 mml mailabbrev mail-utils gmm-utils mailheader mm-view mml-smime
mml-sec epa epg rfc6068 epg-config gnus-util smime gnutls puny dig
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr pdf-occur ibuf-ext ibuffer ibuffer-loaddefs
tablist advice derived tablist-filter semantic/wisent/comp
semantic/wisent semantic/wisent/wisent semantic/util-modes semantic/util
semantic semantic/tag semantic/lex semantic/fw mode-local cedet
pdf-isearch let-alist pdf-misc imenu pdf-tools compile cus-edit cus-load
wid-edit pdf-view bookmark text-property-search pp jka-compr pdf-cache
pdf-info tq pdf-util pdf-macs image-mode dired dired-loaddefs exif
xcscope easy-mmode tramp tramp-loaddefs trampver tramp-integration
files-x tramp-compat shell parse-time iso8601 winner desktop frameset
ido icomplete follow cl-extra help-mode org-modern org ob ob-tangle
ob-ref ob-lob ob-table ob-exp org-macro org-src ob-comint org-pcomplete
pcomplete comint ansi-osc ansi-color ring org-list org-footnote
org-faces org-entities time-date noutline outline icons ob-emacs-lisp
ob-core ob-eval org-cycle org-table ol org-fold org-fold-core org-keys
oc org-loaddefs find-func cal-menu calendar cal-loaddefs org-version
org-compat org-macs format-spec compat finder-inf bison-mode-autoloads
cape-autoloads company-autoloads corfu-autoloads counsel-autoloads
diff-hl-autoloads engine-mode-autoloads expand-region-autoloads
eyebrowse-autoloads flycheck-autoloads fzf-autoloads ggtags-autoloads
graphviz-dot-mode-autoloads json-mode-autoloads rx magit-autoloads pcase
git-commit-autoloads magit-section-autoloads markdown-mode-autoloads
notmuch-autoloads orderless-autoloads org-contrib-autoloads
org-jira-autoloads org-modern-autoloads org-present-autoloads
org-ql-autoloads org-super-agenda-autoloads org-tree-slide-autoloads
ov-autoloads ox-reveal-autoloads org-autoloads pdf-tools-autoloads
peg-autoloads prodigy-autoloads f-autoloads request-autoloads
scala-mode-autoloads svg-lib-autoloads swiper-autoloads ivy-autoloads
tablist-autoloads transient-autoloads treemacs-autoloads
posframe-autoloads ht-autoloads hydra-autoloads pfuture-autoloads
ace-window-autoloads avy-autoloads ts-autoloads s-autoloads
dash-autoloads uniquify-files-autoloads vterm-autoloads wisi-autoloads
with-editor-autoloads info compat-autoloads xcscope-autoloads
yaml-autoloads yaml-mode-autoloads yasnippet-snippets-autoloads
yasnippet-autoloads zenburn-theme-autoloads package browse-url url
url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x
map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 997490 768350)
 (symbols 48 50364 108)
 (strings 32 240148 40216)
 (string-bytes 1 7063652)
 (vectors 16 78565)
 (vector-slots 8 2001387 429278)
 (floats 8 611 782)
 (intervals 56 2767 2910)
 (buffers 984 18))

[-- Attachment #2: Type: text/html, Size: 40621 bytes --]

bug#70760: 29.3.50; core dumps when copy in other apps

[Eli Zaretskii]

> From: Kun Liu <kun.liu@gmail.com>
> Date: Fri, 3 May 2024 14:30:37 -0700
> 
> Emacs is running inside VirtualBox on Windows 11. It randomly crashes
> when I do a copy from other apps running on the host, e.g., Chrome on
> Windows 11.

Emacs seems to segfault trying to display an invalid Lisp object.  The
invalid object seems to come from an error message.  IOW, Emacs tried
to signal an error, and crashed showing the data of the error.  I have
no idea how VirtualBox converts Windows clipboard data into X
clipboard/selection data -- do you happen to know?  The reason of this
problem is probably there.

However, please provide more details, as the backtrace below doesn't
say enough.

First, please say "source src/.gdbinit" in GDB, to have special
commands in .gdbinit defined, which help in debugging Emacs.

Second, please rebuild Emacs with "-O0 -g3", so that debug info is
more comprehensive.

After that, when Emacs crashes, show the backtrace, which should now
include the Lisp backtrace as well (by virtue of src/.gdbinit).

And finally, the values of the following variables are of interest:

> #11 0x000055b069603f3e in print_error_message (data=<optimized out>, data@entry=0x55b085976613,
> stream=stream@entry=0x30, context=<optimized out>, caller=caller@entry=0x7fe0) at lisp.h:1172
>         obj = <optimized out>
>         li = {tortoise = 0x55b0859765f3, max = 2, n = 0, q = 1}
>         sep = 0x55b0696ad6a0 ", "
>         errname = 0x11f40
>         errmsg = 0x55b06c78e6e4
>         file_error = 0x0
>         tail = 0x55b0859765e3

In this call-stack frame, what is the value of 'data'?  It is a Lisp
object, so showing it should involve using the commands xtype, xcar,
and xcdr, and probably also xstring (which are defined in .gdbinit).

Also, if you know what was the text copied from the other application,
please show that text.

Thanks.

bug#70760: 29.3.50; core dumps when copy in other apps

[Kun Liu]

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

On Sat, May 4, 2024 at 12:11 AM Eli Zaretskii <eliz@gnu.org> wrote:

> I have
> no idea how VirtualBox converts Windows clipboard data into X
> clipboard/selection data -- do you happen to know?  The reason of this
> problem is probably there.
>

Sorry I am unfamiliar with how VirtualBox implements this. I know they use
something called guest addition to allow bi-directional clipboard sharing.


> And finally, the values of the following variables are of interest:
>
> > #11 0x000055b069603f3e in print_error_message (data=<optimized out>,
> data@entry=0x55b085976613,
> > stream=stream@entry=0x30, context=<optimized out>, caller=caller@entry=0x7fe0)
> at lisp.h:1172
> >         obj = <optimized out>
> >         li = {tortoise = 0x55b0859765f3, max = 2, n = 0, q = 1}
> >         sep = 0x55b0696ad6a0 ", "
> >         errname = 0x11f40
> >         errmsg = 0x55b06c78e6e4
> >         file_error = 0x0
> >         tail = 0x55b0859765e3
>
> In this call-stack frame, what is the value of 'data'?  It is a Lisp
> object, so showing it should involve using the commands xtype, xcar,
> and xcdr, and probably also xstring (which are defined in .gdbinit).


I did as directed. Emacs soon crashed and here is the analysis:
(gdb) bt full
#0  raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:50
        set = {
          __val = {18446744067266837247, 0 <repeats 15 times>}
        }
        pid = <optimized out>
        tid = <optimized out>
#1  0x0000564c4c3e5cf8 in terminate_due_to_signal (sig=11,
backtrace_limit=40) at emacs.c:464
#2  0x0000564c4c4141b2 in handle_fatal_signal (sig=11) at sysdep.c:1783
#3  0x0000564c4c414187 in deliver_thread_signal (sig=11,
handler=0x564c4c414198 <handle_fatal_signal>) at sysdep.c:1775
        old_errno = 11
#4  0x0000564c4c4141ed in deliver_fatal_thread_signal (sig=11) at
sysdep.c:1795
#5  0x0000564c4c41438b in handle_sigsegv (sig=11, siginfo=0x564c4cb3e230
<sigsegv_stack+64528>, arg=0x564c4cb3e100 <sigsegv_stack+64224>) at
sysdep.c:1888
        fatal = false
#6  0x00007f8907b26140 in <signal handler called> () at
/lib/x86_64-linux-gnu/libpthread.so.0
#7  SYMBOL_NAME (sym=XIL(0x564c55abc5a0)) at lisp.h:2336
#8  0x0000564c4c4e0ca5 in print_object (obj=XIL(0x564c55abc5a0),
printcharfun=XIL(0x30), escapeflag=true) at print.c:2393
        len = 140226424574408
        i = 140729353894864
        name = XIL(0x21974e0)
        size_byte = 94885739624928
        p = 0x564c4c41f35a <set_buffer_internal_2+227> "H\213@
\bH\205\300t\fH\213E\330H\211\307\350\336\362\006"
        signedp = false
        confusing = false
        base_depth = 0
        base_sp = 0
        buf =
"\020H\220SLV\000\000\020H\220SLV\000\000`\205\264LLV\000\000`\000\000\000\000\000\000\000`\000\000\000\000\000\000\000\000\374%\033\376\177\000\000ܖHLLV"
#9  0x0000564c4c4dddb4 in print (obj=XIL(0x564c55abc5a0),
printcharfun=XIL(0x30), escapeflag=true) at print.c:1301
#10 0x0000564c4c4dcc92 in Fprin1 (object=XIL(0x564c55abc5a0),
printcharfun=XIL(0x30), overrides=XIL(0)) at print.c:776
        count = {
          bytes = 224
        }
        pc = {
          printcharfun = XIL(0x30),
          old_printcharfun = XIL(0x30),
          old_point = -1,
          start_point = -1,
          old_point_byte = -1,
          start_point_byte = -1,
          specpdl_count = {
            bytes = 224
          }
        }
#11 0x0000564c4c4dd82f in print_error_message (data=XIL(0x564c52d9c853),
stream=XIL(0x30), context=0x7f89023daa83 "", caller=XIL(0x293cb518a578)) at
print.c:1134
        obj = XIL(0x564c55abc5a0)
        li = {
          tortoise = XIL(0x564c52d9c873),
          max = 2,
          n = 0,
          q = 1
        }
        sep = 0x564c4c5c1c0c ", "
        errname = XIL(0x11f40)
        errmsg = XIL(0x564c520b0a84)
        file_error = XIL(0)
        tail = XIL(0x564c52d9c883)
#12 0x0000564c4c3ed1a9 in Fcommand_error_default_function
(data=XIL(0x564c52d9c853), context=XIL(0x7f8901be9284),
signal=XIL(0x293cb518a578)) at keyboard.c:1070
        sf = 0x564c4ec8f6c8
        conditions = XIL(0x7f89022845e3)
        is_minibuffer_quit = 0
#13 0x0000564c4c4b09a7 in funcall_subr (subr=0x564c4cabd2e0
<Scommand_error_default_function>, numargs=3, args=0x7f89014b1050) at
eval.c:3042
        argbuf = {XIL(0x564c4cb48500), XIL(0), XIL(0), XIL(0x7ffe1b25ffa0),
XIL(0x564c4c4ffe4b), XIL(0x4cabd2e5), XIL(0x7ffe1b25ffc0),
XIL(0x564c4c500741)}
        a = 0x7f89014b1050
        fun = XIL(0x7ffe1b25ffe0)
#14 0x0000564c4c50176b in exec_byte_code (fun=XIL(0x7f890204f18d),
args_template=771, nargs=3, args=0x7ffe1b260640) at bytecode.c:809
        call_nargs = 3
        call_fun = XIL(0x564c4cabd2e5)
        count1 = {
          bytes = 192
        }
        template = XIL(0x21b2600a0)
        val = XIL(0)
        call_args = 0x7f89014b1050
        original_fun = XIL(0x293cb5507120)
        bytecode = make_fixnum(1393703692)
        op = 3
        type = (unknown: 0x2398d60)
        targets =
          {0x564c4c504e7e <exec_byte_code+17280>, 0x564c4c504ea3
<exec_byte_code+17317>, 0x564c4c504ea5 <exec_byte_code+17319>,
0x564c4c504ea7 <exec_byte_code+17321>, 0x564c4c504ea9
<exec_byte_code+17323>, 0x564c4c504ea9 <exec_byte_code+17323>,
0x564c4c504f0e <exec_byte_code+17424>, 0x564c4c504f82
<exec_byte_code+17540>, 0x564c4c500f00 <exec_byte_code+1026>,
0x564c4c500f02 <exec_byte_code+1028>, 0x564c4c500f04 <exec_byte_code+1030>,
0x564c4c500f06 <exec_byte_code+1032>, 0x564c4c500f08 <exec_byte_code+1034>,
0x564c4c500f08 <exec_byte_code+1034>, 0x564c4c500f0e <exec_byte_code+1040>,
0x564c4c500ecf <exec_byte_code+977>, 0x564c4c50128d <exec_byte_code+1935>,
0x564c4c50128f <exec_byte_code+1937>, 0x564c4c501291 <exec_byte_code+1939>,
0x564c4c501293 <exec_byte_code+1941>, 0x564c4c501295 <exec_byte_code+1943>,
0x564c4c501295 <exec_byte_code+1943>, 0x564c4c5012ca <exec_byte_code+1996>,
0x564c4c50129b <exec_byte_code+1949>, 0x564c4c501480 <exec_byte_code+2434>,
0x564c4c501482 <exec_byte_code+2436>, 0x564c4c501484 <exec_byte_code+2438>,
0x564c4c501486 <exec_byte_code+2440>, 0x564c4c501488 <exec_byte_code+2442>,
0x564c4c501488 <exec_byte_code+2442>, 0x564c4c50143a <exec_byte_code+2364>,
0x564c4c501451 <exec_byte_code+2387>, 0x564c4c501535 <exec_byte_code+2615>,
0x564c4c501537 <exec_byte_code+2617>, 0x564c4c501539 <exec_byte_code+2619>,
0x564c4c50153b <exec_byte_code+2621>, 0x564c4c50153d <exec_byte_code+2623>,
0x564c4c50153d <exec_byte_code+2623>, 0x564c4c5014ef <exec_byte_code+2545>,
0x564c4c501506 <exec_byte_code+2568>, 0x564c4c501890 <exec_byte_code+3474>,
0x564c4c501892 <exec_byte_code+3476>, 0x564c4c501894 <exec_byte_code+3478>,
0x564c4c501896 <exec_byte_code+3480>, 0x564c4c501898 <exec_byte_code+3482>,
0x564c4c501898 <exec_byte_code+3482>, 0x564c4c50184a <exec_byte_code+3404>,
0x564c4c501861 <exec_byte_code+3427>, 0x564c4c5020e0 <exec_byte_code+5602>,
0x564c4c501f36 <exec_byte_code+5176>, 0x564c4c501f2d <exec_byte_code+5167>,
0x564c4c504e7e <exec_byte_code+17280>, 0x564c4c504e7e
<exec_byte_code+17280>, 0x564c4c504e7e <exec_byte_code+17280>,
0x564c4c504e7e <exec_byte_code+17280>, 0x564c4c504e7e
<exec_byte_code+17280>, 0x564c4c502325 <exec_byte_code+6183>,
0x564c4c50240f <exec_byte_code+6417>, 0x564c4c502471 <exec_byte_code+6515>,
0x564c4c5024d1 <exec_byte_code+6611>, 0x564c4c502533 <exec_byte_code+6709>,
0x564c4c501113 <exec_byte_code+1557>, 0x564c4c501195 <exec_byte_code+1687>,
0x564c4c5025ac <exec_byte_code+6830>, 0x564c4c501084 <exec_byte_code+1414>,
0x564c4c5011fd <exec_byte_code+1791>, 0x564c4c502614 <exec_byte_code+6934>,
0x564c4c50267c <exec_byte_code+7038>, 0x564c4c5026c4 <exec_byte_code+7110>,
0x564c4c50272c <exec_byte_code+7214>, 0x564c4c502792 <exec_byte_code+7316>,
0x564c4c502878 <exec_byte_code+7546>, 0x564c4c5028c0 <exec_byte_code+7618>,
0x564c4c502a01 <exec_byte_code+7939>, 0x564c4c502b6d <exec_byte_code+8303>,
0x564c4c502bb5 <exec_byte_code+8375>, 0x564c4c502bfd <exec_byte_code+8447>,
0x564c4c502c65 <exec_byte_code+8551>, 0x564c4c502ccd <exec_byte_code+8655>,
0x564c4c502d35 <exec_byte_code+8759>, 0x564c4c502dba <exec_byte_code+8892>,
0x564c4c502e09 <exec_byte_code+8971>, 0x564c4c502e58 <exec_byte_code+9050>,
0x564c4c502f1f <exec_byte_code+9249>, 0x564c4c502fc1 <exec_byte_code+9411>,
0x564c4c503063 <exec_byte_code+9573>, 0x564c4c503132 <exec_byte_code+9780>,
0x564c4c503214 <exec_byte_code+10006>, 0x564c4c5032f6
<exec_byte_code+10232>, 0x564c4c5033d8 <exec_byte_code+10458>,
0x564c4c5034ba <exec_byte_code+10684>, 0x564c4c5035ec
<exec_byte_code+10990>, 0x564c4c50368f <exec_byte_code+11153>,
0x564c4c5037bb <exec_byte_code+11453>, 0x564c4c503881
<exec_byte_code+11651>, 0x564c4c503947 <exec_byte_code+11849>,
0x564c4c503ccb <exec_byte_code+12749>, 0x564c4c501dad
<exec_byte_code+4783>, 0x564c4c503d26 <exec_byte_code+12840>,
0x564c4c503d6e <exec_byte_code+12912>, 0x564c4c503e30
<exec_byte_code+13106>, 0x564c4c503e8b <exec_byte_code+13197>,
0x564c4c503ee6 <exec_byte_code+13288>, 0x564c4c503f2e
<exec_byte_code+13360>, 0x564c4c503f71 <exec_byte_code+13427>,
0x564c4c503fb4 <exec_byte_code+13494>, 0x564c4c503fff
<exec_byte_code+13569>, 0x564c4c504e7e <exec_byte_code+17280>,
0x564c4c504057 <exec_byte_code+13657>, 0x564c4c50409a
<exec_byte_code+13724>, 0x564c4c5040dd <exec_byte_code+13791>,
0x564c4c504120 <exec_byte_code+13858>, 0x564c4c504163
<exec_byte_code+13925>, 0x564c4c5041a6 <exec_byte_code+13992>,
0x564c4c501dad <exec_byte_code+4783>, 0x564c4c504e7e
<exec_byte_code+17280>, 0x564c4c5041ee <exec_byte_code+14064>,
0x564c4c50423e <exec_byte_code+14144>, 0x564c4c504286
<exec_byte_code+14216>, 0x564c4c5042ce <exec_byte_code+14288>,
0x564c4c504336 <exec_byte_code+14392>, 0x564c4c50439e
<exec_byte_code+14496>, 0x564c4c5043e6 <exec_byte_code+14568>,
0x564c4c50442e <exec_byte_code+14640>, 0x564c4c504496
<exec_byte_code+14744>, 0x564c4c5044fe <exec_byte_code+14848>,
0x564c4c504566 <exec_byte_code+14952>, 0x564c4c5045a9
<exec_byte_code+15019>, 0x564c4c504e7e <exec_byte_code+17280>,
0x564c4c501cf7 <exec_byte_code+4601>, 0x564c4c5018fe <exec_byte_code+3584>,
0x564c4c500ff2 <exec_byte_code+1268>, 0x564c4c5019a3 <exec_byte_code+3749>,
0x564c4c501a27 <exec_byte_code+3881>, 0x564c4c501aa8 <exec_byte_code+4010>,
0x564c4c501b29 <exec_byte_code+4139>, 0x564c4c501cc0 <exec_byte_code+4546>,
0x564c4c5013e7 <exec_byte_code+2281>, 0x564c4c501d76 <exec_byte_code+4728>,
0x564c4c501de4 <exec_byte_code+4838>, 0x564c4c501e75 <exec_byte_code+4983>,
0x564c4c501ebe <exec_byte_code+5056>, 0x564c4c50212c <exec_byte_code+5678>,
0x564c4c5021a9 <exec_byte_code+5803>, 0x564c4c50222e <exec_byte_code+5936>,
0x564c4c502294 <exec_byte_code+6038>, 0x564c4c504e7e
<exec_byte_code+17280>, 0x564c4c5045f1 <exec_byte_code+15091>,
0x564c4c504676 <exec_byte_code+15224>, 0x564c4c5046be
<exec_byte_code+15296>, 0x564c4c504706 <exec_byte_code+15368>,
0x564c4c50474e <exec_byte_code+15440>, 0x564c4c504796
<exec_byte_code+15512>, 0x564c4c5047fe <exec_byte_code+15616>,
0x564c4c504866 <exec_byte_code+15720>, 0x564c4c5048ce
<exec_byte_code+15824>, 0x564c4c504936 <exec_byte_code+15928>,
0x564c4c504a47 <exec_byte_code+16201>, 0x564c4c504aaf
<exec_byte_code+16305>, 0x564c4c504b17 <exec_byte_code+16409>,
0x564c4c504b5f <exec_byte_code+16481>, 0x564c4c504c1d
<exec_byte_code+16671>, 0x564c4c504cdb <exec_byte_code+16861>,
0x564c4c504d23 <exec_byte_code+16933>, 0x564c4c504d6b
<exec_byte_code+17005>, 0x564c4c503a85 <exec_byte_code+12167>,
0x564c4c503bd1 <exec_byte_code+12499>, 0x564c4c504dba
<exec_byte_code+17084>, 0x564c4c504e1c <exec_byte_code+17182>,
0x564c4c504e7e <exec_byte_code+17280>, 0x564c4c504e7e
<exec_byte_code+17280>, 0x564c4c504e7e <exec_byte_code+17280>,
0x564c4c504e7e <exec_byte_code+17280>, 0x564c4c504e7e
<exec_byte_code+17280>, 0x564c4c504e7e <exec_byte_code+17280>,
0x564c4c502800 <exec_byte_code+7426>, 0x564c4c502ea7 <exec_byte_code+9129>,
0x564c4c503db8 <exec_byte_code+12986>, 0x564c4c505011
<exec_byte_code+17683>, 0x564c4c505086 <exec_byte_code+17800>,
0x564c4c504e7e <exec_byte_code+17280>, 0x564c4c504e7e
<exec_byte_code+17280>, 0x564c4c505118 <exec_byte_code+17946>,
0x564c4c50519f <exec_byte_code+18081>, 0x564c4c504e7e
<exec_byte_code+17280>, 0x564c4c504e7e <exec_byte_code+17280>,
0x564c4c504e7e <exec_byte_code+17280>, 0x564c4c504e7e
<exec_byte_code+17280>, 0x564c4c504e7e <exec_byte_code+17280>,
0x564c4c504e7e <exec_byte_code+17280>, 0x564c4c504e7e
<exec_byte_code+17280>, 0x564c4c504e7e <exec_byte_code+17280>,
0x564c4c5052f7 <exec_byte_code+18425> <repeats 64 times>}
        quitcounter = 1 '\001'
        bc = 0x564c4cab2410 <main_thread+496>
        top = 0x7f89014b1048
        pc = 0x7f89024b5001 "\210\002:\205:"
        bytestr = XIL(0x7f890204f674)
        vector = XIL(0x7f890204f1cd)
        maxdepth = make_fixnum(11)
        const_length = 7
        bytestr_length = 59
        vectorp = 0x7f890204f1d0
        max_stack = 11
        frame_base = 0x7f89014b1030
        fp = 0x7f89014b1088
        bytestr_data = 0x7f89024b4ffc "\300\003\003\003#\210\002:\205:"
        rest = false
        mandatory = 3
        nonrest = 3
        pushedargs = 3
        result = XIL(0)
#15 0x0000564c4c4b0c6d in fetch_and_exec_byte_code
(fun=XIL(0x7f890204f18d), args_template=771, nargs=3, args=0x7ffe1b260628)
at eval.c:3085
#16 0x0000564c4c4b0fe1 in funcall_lambda (fun=XIL(0x7f890204f18d), nargs=3,
arg_vector=0x7ffe1b260628) at eval.c:3157
        val = XIL(0x7ffe1b260560)
        syms_left = make_fixnum(771)
        next = XIL(0)
        lexenv = XIL(0x1e0204f158)
        count = {
          bytes = 192
        }
        i = 45340716723288
        optional = false
        rest = false
        previous_rest = false
#17 0x0000564c4c4b050d in funcall_general (fun=XIL(0x7f890204f18d),
numargs=3, args=0x7ffe1b260628) at eval.c:2949
        original_fun = XIL(0x293cb5506c58)
#18 0x0000564c4c4b078e in Ffuncall (nargs=4, args=0x7ffe1b260620) at
eval.c:2999
        count = {
          bytes = 160
        }
        val = XIL(0x7ffe1b2605f0)
#19 0x0000564c4c3eaf38 in call3 (fn=XIL(0x293cb5506c58),
arg1=XIL(0x564c52d9c853), arg2=XIL(0x7f8901be9284),
arg3=XIL(0x293cb518a578)) at lisp.h:3262
#20 0x0000564c4c3ecf9f in cmd_error_internal (data=XIL(0x564c52d9c853),
context=0x7ffe1b2606d0 "") at keyboard.c:1013
#21 0x0000564c4c3ece84 in cmd_error (data=XIL(0x564c52d9c853)) at
keyboard.c:981
        old_level = XIL(0)
        old_length = XIL(0)
        count = {
          bytes = 96
        }
        conditions = XIL(0x7f89022845e3)
        macroerror =
"\000\a&\033\376\177\000\000L\316JLLV\000\000\367\213JL\001\000\000\000`\000\000\000\000\000\000\000\060\a&\033\376\177\000\000\324S\316RLV\000\000\000"
#22 0x0000564c4c4ac9ee in internal_condition_case (bfun=0x564c4c3ed64e
<command_loop_1>, handlers=XIL(0x90), hfun=0x564c4c3ecc8c <cmd_error>) at
eval.c:1470
        val = XIL(0x564c52d9c853)
        c = 0x564c4e5443e0
#23 0x0000564c4c3ed316 in command_loop_2 (handlers=XIL(0x90)) at
keyboard.c:1133
        val = make_fixnum(0)
#24 0x0000564c4c4ac0be in internal_catch (tag=XIL(0x10080),
func=0x564c4c3ed2ef <command_loop_2>, arg=XIL(0x90)) at eval.c:1197
        val = XIL(0x7ffe1b260810)
        c = 0x564c4e5424c0
#25 0x0000564c4c3ed2ab in command_loop () at keyboard.c:1111
#26 0x0000564c4c3ec837 in recursive_edit_1 () at keyboard.c:720
        count = {
          bytes = 32
        }
        val = make_fixnum(23721424373675)
#27 0x0000564c4c3ec9e0 in Frecursive_edit () at keyboard.c:803
        count = {
          bytes = 0
        }
        buffer = XIL(0)
#28 0x0000564c4c3e8dbf in main (argc=1, argv=0x7ffe1b260af8) at emacs.c:2521
        stack_bottom_variable = 0x564c4e4a3f20
        no_loadup = false
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x0
        original_pwd = 0x0
        dump_mode = 0x0
        skip_args = 0
        temacs = 0x0
        attempt_load_pdump = true
        only_version = false
        rlim = {
          rlim_cur = 10022912,
          rlim_max = 18446744073709551615
        }
        lc_all = 0x0
        sockfd = -1
        module_assertions = false
You can't do that without a process to debug.
(gdb) frame 11
#11 0x0000564c4c4dd82f in print_error_message (data=XIL(0x564c52d9c853),
stream=XIL(0x30), context=0x7f89023daa83 "", caller=XIL(0x293cb518a578)) at
print.c:1134
1134  Fprin1 (obj, stream, Qnil);
(gdb) info locals
obj = XIL(0x564c55abc5a0)
li = {
  tortoise = XIL(0x564c52d9c873),
  max = 2,
  n = 0,
  q = 1
}
sep = 0x564c4c5c1c0c ", "
errname = XIL(0x11f40)
errmsg = XIL(0x564c520b0a84)
file_error = XIL(0)
tail = XIL(0x564c52d9c883)

(gdb) print data
$1 = XIL(0x564c52d9c853)
(gdb) xtype data
Lisp_Cons
(gdb) xcar data
$2 = 0x11f40
(gdb) xcdr data
$3 = 0x0
(gdb) xstring data
$4 = (struct Lisp_String *) 0x0
"DEAD"

(gdb) print obj
$31 = XIL(0x564c55abc5a0)
(gdb) xtype obj
Lisp_Symbol
(gdb) xcar obj
$32 = 0x0
(gdb) xcdr obj
$33 = 0x0
(gdb) xstring obj
$34 = (struct Lisp_String *) 0x0
"DEAD"

(gdb) print li
$35 = {
  tortoise = XIL(0x564c52d9c873),
  max = 2,
  n = 0,
  q = 1
}
(gdb) xtype li
Invalid cast.
(gdb) xcar li
Invalid cast.
(gdb) xcdr li
Invalid cast.
(gdb) xstring li
Invalid cast.

(gdb) print sep
$36 = 0x564c4c5c1c0c ", "
(gdb) xtype sep
Lisp_String
(gdb) xcar sep
$37 = 0x0
(gdb) xcdr sep
$38 = 0x0
(gdb) xstring sep
$39 = (struct Lisp_String *) 0x0
"DEAD"

(gdb) print errname
$40 = XIL(0x11f40)
(gdb) xtype errname
Lisp_Symbol
(gdb) xcar errname
$41 = 0x0
(gdb) xcdr errname
$42 = 0x0
(gdb) xstring errname
$43 = (struct Lisp_String *) 0x0
"DEAD"

(gdb) print errmsg
$44 = XIL(0x564c520b0a84)
(gdb) xtype errmsg
Lisp_String
(gdb) xcar errmsg
$45 = 0x0
(gdb) xcdr errmsg
$46 = 0x0
(gdb) xstring errmsg
$47 = (struct Lisp_String *) 0x0
"DEAD"

(gdb) print file
No symbol "file" in current context.
(gdb) xtype file
Lisp_Symbol
(gdb) xcar file
$48 = 0x0
(gdb) xcdr file
$49 = 0x0
(gdb) xstring file
$50 = (struct Lisp_String *) 0x0
"DEAD"

(gdb) print tail
$51 = XIL(0x564c52d9c883)
(gdb) xtype tail
Lisp_Cons
(gdb) xcar tail
$52 = 0x564c55abc5a0
(gdb) xcdr tail
$53 = 0x0
(gdb) xstring tail
$54 = (struct Lisp_String *) 0x0
"DEAD"


> Also, if you know what was the text copied from the other application,
> please show that text.
>

It seems to crash randomly. I will try to note down what I copied next time
it crashes.

[-- Attachment #2: Type: text/html, Size: 21907 bytes --]

bug#70760: 29.3.50; core dumps when copy in other apps

[Eli Zaretskii]

> From: Kun Liu <kun.liu@gmail.com>
> Date: Sat, 4 May 2024 11:08:31 -0700
> Cc: 70760@debbugs.gnu.org
> 
> (gdb) xtype data
> Lisp_Cons
> (gdb) xcar data
> $2 = 0x11f40
> (gdb) xcdr data
> $3 = 0x0
> (gdb) xstring data
> $4 = (struct Lisp_String *) 0x0
> "DEAD"

This is not how you explore a cons cell in GDB.  The correct sequence
is:

  (gdb) print data
  (gdb) xtype

If "xtype" says it's a cons cell, the next command should be "xcar",
followed by "xtype", to show the type of car.  If "xtype" says it's a
symbol, the next command should be "xsymbol", to show the symbol's
name.  Once you are done with car, continue to cdr, like this:

  (gdb) print data
  (gdb) xcdr
  (gdb) xtype

Then again use the appropriate command given what "xtype" says.  Etc.,
etc.

Also, do you remember what you did in Emacs when it crashed?  Was it
C-y or something similar?

bug#70760: 29.3.50; core dumps when copy in other apps

[Kun Liu]

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

+  70760@debbugs.gnu.org

On Sat, May 4, 2024 at 1:49 PM Kun Liu <kun.liu@gmail.com> wrote:

> Thank you, Eli.
>
> Here is the result.
>
> (gdb) print data
> $1 = XIL(0x55f268372323)
> (gdb) xtype
> Lisp_Cons
> (gdb) xcar
> $2 = 0x11f40
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $3 = (struct Lisp_Symbol *) 0x55f2626ad440 <lispsym+73536>
> "wrong-type-argument"
>
> To your question, I wasn't doing anything in Emacs. I was just copying in
> Chrome.
>
> Also I upgraded VirtualBox from 6 to 7. And looks like Emacs is no longer
> crashing. Now it reports the following in mini-bufffer:
>
> funcall-interactively: Wrong type argument: listp, [(2 19 1) ((emacs
> (24))) "A modern list library for Emacs" tar ((:commit .
> "39d067b9fbb2db65fc7a6938bfb21489ad990cb4") (:authors ("Magnar Sveen" . "
> magnars@gmail.com")) (:maintainers ("Magnar Sveen" . "magnars@gmail.com"))
> (:maintainer "Magnar Sveen" . "magnars@gmail.com") (:keywords
> "extensions" "lisp") (:url . "https://github.com/magnars/dash.el"))]
>
> On Sat, May 4, 2024 at 12:02 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > From: Kun Liu <kun.liu@gmail.com>
>> > Date: Sat, 4 May 2024 11:08:31 -0700
>> > Cc: 70760@debbugs.gnu.org
>> >
>> > (gdb) xtype data
>> > Lisp_Cons
>> > (gdb) xcar data
>> > $2 = 0x11f40
>> > (gdb) xcdr data
>> > $3 = 0x0
>> > (gdb) xstring data
>> > $4 = (struct Lisp_String *) 0x0
>> > "DEAD"
>>
>> This is not how you explore a cons cell in GDB.  The correct sequence
>> is:
>>
>>   (gdb) print data
>>   (gdb) xtype
>>
>> If "xtype" says it's a cons cell, the next command should be "xcar",
>> followed by "xtype", to show the type of car.  If "xtype" says it's a
>> symbol, the next command should be "xsymbol", to show the symbol's
>> name.  Once you are done with car, continue to cdr, like this:
>>
>>   (gdb) print data
>>   (gdb) xcdr
>>   (gdb) xtype
>>
>> Then again use the appropriate command given what "xtype" says.  Etc.,
>> etc.
>>
>> Also, do you remember what you did in Emacs when it crashed?  Was it
>> C-y or something similar?
>>
>

[-- Attachment #2: Type: text/html, Size: 3461 bytes --]

bug#70760: 29.3.50; core dumps when copy in other apps

[Eli Zaretskii]

> From: Kun Liu <kun.liu@gmail.com>
> Date: Sat, 4 May 2024 13:49:41 -0700
> 
> (gdb) print data
> $1 = XIL(0x55f268372323)
> (gdb) xtype
> Lisp_Cons
> (gdb) xcar
> $2 = 0x11f40
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $3 = (struct Lisp_Symbol *) 0x55f2626ad440 <lispsym+73536>
> "wrong-type-argument"
> 
> To your question, I wasn't doing anything in Emacs. I was just copying in Chrome.
> 
> Also I upgraded VirtualBox from 6 to 7. And looks like Emacs is no longer crashing. Now it reports the following
> in mini-bufffer:
> 
> funcall-interactively: Wrong type argument: listp, [(2 19 1) ((emacs (24))) "A modern list library for Emacs" tar
> ((:commit . "39d067b9fbb2db65fc7a6938bfb21489ad990cb4") (:authors ("Magnar Sveen" .
> "magnars@gmail.com")) (:maintainers ("Magnar Sveen" . "magnars@gmail.com")) (:maintainer "Magnar
> Sveen" . "magnars@gmail.com") (:keywords "extensions" "lisp") (:url . "https://github.com/magnars/dash.el"))]

What were you copying in Chrome when this happened?  Was it text or
some other entity.  Does the text/object you were copying have
anything in common with the data of the error message above?  Can you
tell what URL to go to and which part of the page to copy, to
reproduce what you did?

Also, please set debug-on-error to a non-nil value, and post the Lisp
backtrace you get when these errors happen.

bug#70760: 29.3.50; core dumps when copy in other apps

[Kun Liu]

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

I did (setq debug-on-error t), went to https://en.wikipedia.org/wiki/Emacs,
randomly selected a fragment "Emacs has over", then did a ctrll+c.

Emacs in VirtualBox immediately showed the following:

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  dbus-handle-event((dbus-event "[ \11]*$"))
  funcall-interactively(dbus-handle-event (dbus-event "[ \11]*$"))
  call-interactively(dbus-handle-event nil [(dbus-event "[ \11]*$")])
  command-execute(dbus-handle-event nil [(dbus-event "[ \11]*$")] t)

On Sat, May 4, 2024 at 10:11 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Kun Liu <kun.liu@gmail.com>
> > Date: Sat, 4 May 2024 13:49:41 -0700
> >
> > (gdb) print data
> > $1 = XIL(0x55f268372323)
> > (gdb) xtype
> > Lisp_Cons
> > (gdb) xcar
> > $2 = 0x11f40
> > (gdb) xtype
> > Lisp_Symbol
> > (gdb) xsymbol
> > $3 = (struct Lisp_Symbol *) 0x55f2626ad440 <lispsym+73536>
> > "wrong-type-argument"
> >
> > To your question, I wasn't doing anything in Emacs. I was just copying
> in Chrome.
> >
> > Also I upgraded VirtualBox from 6 to 7. And looks like Emacs is no
> longer crashing. Now it reports the following
> > in mini-bufffer:
> >
> > funcall-interactively: Wrong type argument: listp, [(2 19 1) ((emacs
> (24))) "A modern list library for Emacs" tar
> > ((:commit . "39d067b9fbb2db65fc7a6938bfb21489ad990cb4") (:authors
> ("Magnar Sveen" .
> > "magnars@gmail.com")) (:maintainers ("Magnar Sveen" . "magnars@gmail.com"))
> (:maintainer "Magnar
> > Sveen" . "magnars@gmail.com") (:keywords "extensions" "lisp") (:url . "
> https://github.com/magnars/dash.el"))]
>
> What were you copying in Chrome when this happened?  Was it text or
> some other entity.  Does the text/object you were copying have
> anything in common with the data of the error message above?  Can you
> tell what URL to go to and which part of the page to copy, to
> reproduce what you did?
>
> Also, please set debug-on-error to a non-nil value, and post the Lisp
> backtrace you get when these errors happen.
>

[-- Attachment #2: Type: text/html, Size: 3556 bytes --]

bug#70760: 29.3.50; core dumps when copy in other apps

[Eli Zaretskii]

> From: Kun Liu <kun.liu@gmail.com>
> Date: Sun, 5 May 2024 08:45:34 -0700
> Cc: 70760@debbugs.gnu.org
> 
> I did (setq debug-on-error t), went to https://en.wikipedia.org/wiki/Emacs, randomly selected a fragment
> "Emacs has over", then did a ctrll+c.
> 
> Emacs in VirtualBox immediately showed the following:
> 
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>   dbus-handle-event((dbus-event "[ \11]*$"))
>   funcall-interactively(dbus-handle-event (dbus-event "[ \11]*$"))
>   call-interactively(dbus-handle-event nil [(dbus-event "[ \11]*$")])
>   command-execute(dbus-handle-event nil [(dbus-event "[ \11]*$")] t)

Does VirtualBox have anything in its documentation that suggests that
Ctrl-C on the Windows side will cause a D-Bus event on the VM side?

Michael, any idea what is this D-Bus event, and what does it have to
do with copying into the Windows clipboard?

Thanks.

bug#70760: 29.3.50; core dumps when copy in other apps

[Kun Liu]

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

I am not sure how VirtualBox deals with Ctrl-C on the Windows side. I
will look into it when I have time.

I did more tests. Observations:

1) It *appears* that the problem is there only when I have a shell buffer
(M-x shell). I will do more tests and report back.

2) The error messages seem to vary. For example, I saw the following two
different ones when copying:

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  dbus-handle-event((dbus-event (calendar-cursor-holidays
(calendar-current-date))))
  funcall-interactively(dbus-handle-event (dbus-event
(calendar-cursor-holidays (calendar-current-date))))
  command-execute(dbus-handle-event nil [(dbus-event
(calendar-cursor-holidays (calendar-current-date)))] t)

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  dbus-handle-event((dbus-event (if above 1 2)))
  funcall-interactively(dbus-handle-event (dbus-event (if above 1 2)))
  command-execute(dbus-handle-event nil [(dbus-event (if above 1 2))] t)

On Sun, May 5, 2024 at 9:12 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Kun Liu <kun.liu@gmail.com>
> > Date: Sun, 5 May 2024 08:45:34 -0700
> > Cc: 70760@debbugs.gnu.org
> >
> > I did (setq debug-on-error t), went to
> https://en.wikipedia.org/wiki/Emacs, randomly selected a fragment
> > "Emacs has over", then did a ctrll+c.
> >
> > Emacs in VirtualBox immediately showed the following:
> >
> > Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p
> nil)
> >   dbus-handle-event((dbus-event "[ \11]*$"))
> >   funcall-interactively(dbus-handle-event (dbus-event "[ \11]*$"))
> >   call-interactively(dbus-handle-event nil [(dbus-event "[ \11]*$")])
> >   command-execute(dbus-handle-event nil [(dbus-event "[ \11]*$")] t)
>
> Does VirtualBox have anything in its documentation that suggests that
> Ctrl-C on the Windows side will cause a D-Bus event on the VM side?
>
> Michael, any idea what is this D-Bus event, and what does it have to
> do with copying into the Windows clipboard?
>
> Thanks.
>

[-- Attachment #2: Type: text/html, Size: 2825 bytes --]

bug#70760: 29.3.50; core dumps when copy in other apps

[Kun Liu]

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

Scratch that. Just now I was able to see the following error in Emacs
without any shell buffer, while copying in Chome:

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  dbus-handle-event((dbus-event (if above 1 2)))
  funcall-interactively(dbus-handle-event (dbus-event (if above 1 2)))
  command-execute(dbus-handle-event nil [(dbus-event (if above 1 2))] t)

On Sun, May 5, 2024 at 9:44 AM Kun Liu <kun.liu@gmail.com> wrote:

> I am not sure how VirtualBox deals with Ctrl-C on the Windows side. I
> will look into it when I have time.
>
> I did more tests. Observations:
>
> 1) It *appears* that the problem is there only when I have a shell buffer
> (M-x shell). I will do more tests and report back.
>
> 2) The error messages seem to vary. For example, I saw the following two
> different ones when copying:
>
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>   dbus-handle-event((dbus-event (calendar-cursor-holidays
> (calendar-current-date))))
>   funcall-interactively(dbus-handle-event (dbus-event
> (calendar-cursor-holidays (calendar-current-date))))
>   command-execute(dbus-handle-event nil [(dbus-event
> (calendar-cursor-holidays (calendar-current-date)))] t)
>
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>   dbus-handle-event((dbus-event (if above 1 2)))
>   funcall-interactively(dbus-handle-event (dbus-event (if above 1 2)))
>   command-execute(dbus-handle-event nil [(dbus-event (if above 1 2))] t)
>
> On Sun, May 5, 2024 at 9:12 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > From: Kun Liu <kun.liu@gmail.com>
>> > Date: Sun, 5 May 2024 08:45:34 -0700
>> > Cc: 70760@debbugs.gnu.org
>> >
>> > I did (setq debug-on-error t), went to
>> https://en.wikipedia.org/wiki/Emacs, randomly selected a fragment
>> > "Emacs has over", then did a ctrll+c.
>> >
>> > Emacs in VirtualBox immediately showed the following:
>> >
>> > Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p
>> nil)
>> >   dbus-handle-event((dbus-event "[ \11]*$"))
>> >   funcall-interactively(dbus-handle-event (dbus-event "[ \11]*$"))
>> >   call-interactively(dbus-handle-event nil [(dbus-event "[ \11]*$")])
>> >   command-execute(dbus-handle-event nil [(dbus-event "[ \11]*$")] t)
>>
>> Does VirtualBox have anything in its documentation that suggests that
>> Ctrl-C on the Windows side will cause a D-Bus event on the VM side?
>>
>> Michael, any idea what is this D-Bus event, and what does it have to
>> do with copying into the Windows clipboard?
>>
>> Thanks.
>>
>

[-- Attachment #2: Type: text/html, Size: 3617 bytes --]

bug#70760: 29.3.50; core dumps when copy in other apps

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> I did (setq debug-on-error t), went to https://en.wikipedia.org/wiki/Emacs, randomly selected a fragment
>> "Emacs has over", then did a ctrll+c.
>>
>> Emacs in VirtualBox immediately showed the following:
>>
>> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>>   dbus-handle-event((dbus-event "[ \11]*$"))
>>   funcall-interactively(dbus-handle-event (dbus-event "[ \11]*$"))
>>   call-interactively(dbus-handle-event nil [(dbus-event "[ \11]*$")])
>>   command-execute(dbus-handle-event nil [(dbus-event "[ \11]*$")] t)
>
> Does VirtualBox have anything in its documentation that suggests that
> Ctrl-C on the Windows side will cause a D-Bus event on the VM side?
>
> Michael, any idea what is this D-Bus event, and what does it have to
> do with copying into the Windows clipboard?

`dbus-handle-event' is the handler for D-Bus events (sic!). It is
invoked, when a D-Bus event arrives in the keyboard buffer, see
`special-event-map'.

It isn't called explicitly anywhere in Emacs. So I assume that the
"D-Bus" event is pushed to the keyboard buffer by accident, when
communicating with the VirtualBox.

> Thanks.

Best regards, Michael.

bug#70760: 29.3.50; core dumps when copy in other apps

[Kun Liu]

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

I tried various things including upgrading the guest Linux to Debian 12,
and trying master vs 29 branches. Still seeing crashes.

Today I tried configure emacs 29 without "--with-native-compilation". It
appears that core dump is no longer happening. Now when I copy on the host,
I see the following message in Emacs:

dbus-check-event: D-Bus error: "Not a valid D-Bus event", (dbus-event 10 14)

Backtrace buffer shows the following:

Debugger entered--Lisp error: (dbus-error "Not a valid D-Bus event"
(dbus-event 10 14))
  signal(dbus-error ("Not a valid D-Bus event" (dbus-event 10 14)))
  dbus-check-event((dbus-event 10 14))
  dbus-event-bus-name((dbus-event 10 14))
  dbus-notice-synchronous-call-errors((dbus-event 10 14) (dbus-error "Not a
valid D-Bus event" (dbus-event 10 14)))
  run-hook-with-args(dbus-notice-synchronous-call-errors (dbus-event 10 14)
(dbus-error "Not a valid D-Bus event" (dbus-event 10 14)))
  dbus-handle-event((dbus-event 10 14))
  funcall-interactively(dbus-handle-event (dbus-event 10 14))
  call-interactively(dbus-handle-event nil [(dbus-event 10 14)])
  command-execute(dbus-handle-event nil [(dbus-event 10 14)] t)

On Sun, May 5, 2024 at 10:34 AM Michael Albinus <michael.albinus@gmx.de>
wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> Hi Eli,
>
> >> I did (setq debug-on-error t), went to
> https://en.wikipedia.org/wiki/Emacs, randomly selected a fragment
> >> "Emacs has over", then did a ctrll+c.
> >>
> >> Emacs in VirtualBox immediately showed the following:
> >>
> >> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p
> nil)
> >>   dbus-handle-event((dbus-event "[ \11]*$"))
> >>   funcall-interactively(dbus-handle-event (dbus-event "[ \11]*$"))
> >>   call-interactively(dbus-handle-event nil [(dbus-event "[ \11]*$")])
> >>   command-execute(dbus-handle-event nil [(dbus-event "[ \11]*$")] t)
> >
> > Does VirtualBox have anything in its documentation that suggests that
> > Ctrl-C on the Windows side will cause a D-Bus event on the VM side?
> >
> > Michael, any idea what is this D-Bus event, and what does it have to
> > do with copying into the Windows clipboard?
>
> `dbus-handle-event' is the handler for D-Bus events (sic!). It is
> invoked, when a D-Bus event arrives in the keyboard buffer, see
> `special-event-map'.
>
> It isn't called explicitly anywhere in Emacs. So I assume that the
> "D-Bus" event is pushed to the keyboard buffer by accident, when
> communicating with the VirtualBox.
>
> > Thanks.
>
> Best regards, Michael.
>

[-- Attachment #2: Type: text/html, Size: 3398 bytes --]

bug#70760: 29.3.50; core dumps when copy in other apps

[Eli Zaretskii]

> From: Kun Liu <kun.liu@gmail.com>
> Date: Mon, 13 May 2024 23:17:16 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>, 70760@debbugs.gnu.org
> 
> I tried various things including upgrading the guest Linux to Debian 12, and trying master vs 29 branches. Still
> seeing crashes.
> 
> Today I tried configure emacs 29 without "--with-native-compilation". It appears that core dump is no longer
> happening. Now when I copy on the host, I see the following message in Emacs:
> 
> dbus-check-event: D-Bus error: "Not a valid D-Bus event", (dbus-event 10 14)
> 
> Backtrace buffer shows the following:
> 
> Debugger entered--Lisp error: (dbus-error "Not a valid D-Bus event" (dbus-event 10 14))
>   signal(dbus-error ("Not a valid D-Bus event" (dbus-event 10 14)))
>   dbus-check-event((dbus-event 10 14))
>   dbus-event-bus-name((dbus-event 10 14))
>   dbus-notice-synchronous-call-errors((dbus-event 10 14) (dbus-error "Not a valid D-Bus event" (dbus-event 10
> 14)))
>   run-hook-with-args(dbus-notice-synchronous-call-errors (dbus-event 10 14) (dbus-error "Not a valid D-Bus
> event" (dbus-event 10 14)))
>   dbus-handle-event((dbus-event 10 14))
>   funcall-interactively(dbus-handle-event (dbus-event 10 14))
>   call-interactively(dbus-handle-event nil [(dbus-event 10 14)])
>   command-execute(dbus-handle-event nil [(dbus-event 10 14)] t)

We have already established that some invalid D-Bus events cause these
problems.  What we need now is to find out what kind of D-Bus events
are those, and what does VirtualBox mean to happen when it emits these
D-Bus events?

Looking at dbus-check-event, I see that event of the form

  (dbus-event 10 14)

is invalid because the first member of the list after 'dbus-event'
should be either a keyword (a symbol, AFAIU) or a string, but here we
have a number.

The event

  (dbus-event "[ \11]*$")

from your previous message is also invalid, since it has only one
member after 'dbus-event'.

IOW, VirtualBox is emitting invalid D-Bus events, at least as far as
our support for D-Bus is concerned.

Michael, are these events invalid according to the D-Bus spec, or we
just lack support for them in Emacs?  If the former, I don't see how
this can be an Emacs problem; you should ask the VirtualBox folks what
to do to avoid this.

Maybe we can make Emacs more tolerant to these issues, e.g., make the
error a warning or a message?

Reading the VirtualBox documentation I find on the net, I see that
this page:

  https://www.virtualbox.org/manual/ch04.html#guestadd-dnd

says you need to install "the latest version of the Guest Additions".
Since copy/paste is a variant of drag-and-drop, perhaps this is
relevant for your case as well, I don't know.  See also

  https://www.virtualbox.org/manual/ch04.html#guestadd-dnd-limitations

The following pages might also be relevant:

  https://www.virtualbox.org/manual/ch12.html#ts_linux-guest-x11-services
  https://www.virtualbox.org/manual/ch12.html#ts_win-dnd-uipi

All in all, I feel like this is not an Emacs issue at all, and should
not be brought to us.

bug#70760: 29.3.50; core dumps when copy in other apps

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

Hi,

> We have already established that some invalid D-Bus events cause these
> problems.  What we need now is to find out what kind of D-Bus events
> are those, and what does VirtualBox mean to happen when it emits these
> D-Bus events?
>
> Looking at dbus-check-event, I see that event of the form
>
>   (dbus-event 10 14)
>
> is invalid because the first member of the list after 'dbus-event'
> should be either a keyword (a symbol, AFAIU) or a string, but here we
> have a number.
>
> The event
>
>   (dbus-event "[ \11]*$")
>
> from your previous message is also invalid, since it has only one
> member after 'dbus-event'.
>
> IOW, VirtualBox is emitting invalid D-Bus events, at least as far as
> our support for D-Bus is concerned.
>
> Michael, are these events invalid according to the D-Bus spec, or we
> just lack support for them in Emacs?  If the former, I don't see how
> this can be an Emacs problem; you should ask the VirtualBox folks what
> to do to avoid this.

These aren't valid D-Bus events according to the spec, and I doubt that
they come from D-Bus itself. But let's instrument Emacs in order to see
which D-Bus events flow around. The following recipe:

--8<---------------cut here---------------start------------->8---
# rm src/dbusbind.o
# make MYCPPFLAGS='-DDBUS_DEBUG'
# src/emacs --eval '(setq dbus-debug t message-log-max t)'
--8<---------------cut here---------------end--------------->8---

Then trigger the problem, and send us the *Messages* buffer afterwards.
Recompile Emacs w/o the MYCPPFLAGS arg.

> Maybe we can make Emacs more tolerant to these issues, e.g., make the
> error a warning or a message?

Maybe. But my gut feeling tells me there is an error in Emacs handling
incoming event. And this isn't related to D-Bus, necessarily.

> All in all, I feel like this is not an Emacs issue at all, and should
> not be brought to us.

Maybe. But I'd like to see the D-Bus events first.

Best regards, Michael.

bug#70760: 29.3.50; core dumps when copy in other apps

[Kun Liu]

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

I did as instructed.

Here is a couple of instances of what I saw in *Messages* right after I was
able to trigger the problem.

case 1:

DBus-Event (dbus-event :post-blank 0 :post-affiliated 1455145 :mode nil
:granularity element :cached t :parent (section (:begin 1179957 :end
1609350 :contents-begin 1179957 :contents-end 1609349 :robust-begin 1179957
:robust-end 1609347 :post-blank 1 :post-affiliated 1179957 :mode section
:granularity element :cached t :parent (headline (:raw-value Old stuff
:begin 1179945 :end 1609350 :pre-blank 0 :contents-begin 1179957
:contents-end 1609349 :robust-begin 1180109 :robust-end 1609347 :level 1
:priority nil :tags nil :todo-keyword nil :todo-type nil :post-blank 1
:footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated
1179945 :ARCHIVE_TIME 2020-10-17 Sat 15:00 :ARCHIVE_FILE ~/work/worklog.org
:ARCHIVE_OLPATH Scratch :ARCHIVE_CATEGORY worklog :title Old stuff :mode
nil :granularity element :cached t :parent (org-data (:begin 1
:contents-begin 1 :contents-end 15432855 :end 15432856 :robust-begin 3
:robust-end 15432853 :post-blank 1 :post-affiliated 1 :path
/home/kun/work/worklog.org_archive :mode org-data :CATEGORY worklog :cached
t :org-element--cache-sync-key nil)) :org-element--cache-sync-key nil))
:org-element--cache-sync-key nil)) :org-element--cache-sync-key nil) [2
times]
Entering debugger...
DBus-Event (dbus-event x . make4ht)
funcall-interactively: Wrong type argument: listp, "make4ht"

case 2:

DBus-Event (dbus-event :post-blank 0 :post-affiliated 1455145 :mode nil
:granularity element :cached t :parent (section (:begin 1179957 :end
1609350 :contents-begin 1179957 :contents-end 1609349 :robust-begin 1179957
:robust-end 1609347 :post-blank 1 :post-affiliated 1179957 :mode section
:granularity element :cached t :parent (headline (:raw-value Old stuff
:begin 1179945 :end 1609350 :pre-blank 0 :contents-begin 1179957
:contents-end 1609349 :robust-begin 1180109 :robust-end 1609347 :level 1
:priority nil :tags nil :todo-keyword nil :todo-type nil :post-blank 1
:footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated
1179945 :ARCHIVE_TIME 2020-10-17 Sat 15:00 :ARCHIVE_FILE ~/work/worklog.org
:ARCHIVE_OLPATH Scratch :ARCHIVE_CATEGORY worklog :title Old stuff :mode
nil :granularity element :cached t :parent (org-data (:begin 1
:contents-begin 1 :contents-end 15432855 :end 15432856 :robust-begin 3
:robust-end 15432853 :post-blank 1 :post-affiliated 1 :path
/home/kun/work/worklog.org_archive :mode org-data :CATEGORY worklog :cached
t :org-element--cache-sync-key nil)) :org-element--cache-sync-key nil))
:org-element--cache-sync-key nil)) :org-element--cache-sync-key nil) [2
times]
dbus-event-bus-name: D-Bus error: "Not a valid D-Bus event", (dbus-event
:post-blank 0 :post-affiliated 1455145 :mode nil :granularity element
:cached ...)


On Wed, May 15, 2024 at 3:35 AM Michael Albinus <michael.albinus@gmx.de>
wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> Hi,
>
> > We have already established that some invalid D-Bus events cause these
> > problems.  What we need now is to find out what kind of D-Bus events
> > are those, and what does VirtualBox mean to happen when it emits these
> > D-Bus events?
> >
> > Looking at dbus-check-event, I see that event of the form
> >
> >   (dbus-event 10 14)
> >
> > is invalid because the first member of the list after 'dbus-event'
> > should be either a keyword (a symbol, AFAIU) or a string, but here we
> > have a number.
> >
> > The event
> >
> >   (dbus-event "[ \11]*$")
> >
> > from your previous message is also invalid, since it has only one
> > member after 'dbus-event'.
> >
> > IOW, VirtualBox is emitting invalid D-Bus events, at least as far as
> > our support for D-Bus is concerned.
> >
> > Michael, are these events invalid according to the D-Bus spec, or we
> > just lack support for them in Emacs?  If the former, I don't see how
> > this can be an Emacs problem; you should ask the VirtualBox folks what
> > to do to avoid this.
>
> These aren't valid D-Bus events according to the spec, and I doubt that
> they come from D-Bus itself. But let's instrument Emacs in order to see
> which D-Bus events flow around. The following recipe:
>
> --8<---------------cut here---------------start------------->8---
> # rm src/dbusbind.o
> # make MYCPPFLAGS='-DDBUS_DEBUG'
> # src/emacs --eval '(setq dbus-debug t message-log-max t)'
> --8<---------------cut here---------------end--------------->8---
>
> Then trigger the problem, and send us the *Messages* buffer afterwards.
> Recompile Emacs w/o the MYCPPFLAGS arg.
>
> > Maybe we can make Emacs more tolerant to these issues, e.g., make the
> > error a warning or a message?
>
> Maybe. But my gut feeling tells me there is an error in Emacs handling
> incoming event. And this isn't related to D-Bus, necessarily.
>
> > All in all, I feel like this is not an Emacs issue at all, and should
> > not be brought to us.
>
> Maybe. But I'd like to see the D-Bus events first.
>
> Best regards, Michael.
>

[-- Attachment #2: Type: text/html, Size: 5952 bytes --]

bug#70760: 29.3.50; core dumps when copy in other apps

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Kun Liu <kun.liu@gmail.com> writes:

Hi,

> Here is a couple of instances of what I saw in *Messages* right after
> I was able to trigger the problem.

So no messages from dbusbond.c, which is good for analysis: the events
haven't benn inserted via the D-Bus system of your machine.

> case 1:
>
> DBus-Event (dbus-event :post-blank 0 :post-affiliated 1455145 :mode
> nil :granularity element :cached t :parent (section (:begin 1179957 :
> end 1609350 :contents-begin 1179957 :contents-end 1609349 :
> robust-begin 1179957 :robust-end 1609347 :post-blank 1 :
> post-affiliated 1179957 :mode section :granularity element :cached t :
> parent (headline (:raw-value Old stuff :begin 1179945 :end 1609350 :
> pre-blank 0 :contents-begin 1179957 :contents-end 1609349 :
> robust-begin 1180109 :robust-end 1609347 :level 1 :priority nil :tags
> nil :todo-keyword nil :todo-type nil :post-blank 1 :footnote-section-p
> nil :archivedp nil :commentedp nil :post-affiliated 1179945 :
> ARCHIVE_TIME 2020-10-17 Sat 15:00 :ARCHIVE_FILE ~/work/worklog.org :
> ARCHIVE_OLPATH Scratch :ARCHIVE_CATEGORY worklog :title Old stuff :
> mode nil :granularity element :cached t :parent (org-data (:begin 1 :
> contents-begin 1 :contents-end 15432855 :end 15432856 :robust-begin 3 :
> robust-end 15432853 :post-blank 1 :post-affiliated 1 :path
> /home/kun/work/worklog.org_archive :mode org-data :CATEGORY worklog :
> cached t :org-element--cache-sync-key nil)) :
> org-element--cache-sync-key nil)) :org-element--cache-sync-key nil)) :
> org-element--cache-sync-key nil) [2 times]
> Entering debugger...
> DBus-Event (dbus-event x . make4ht)
> funcall-interactively: Wrong type argument: listp, "make4ht"

The :post-blank keyword exist in org/*.el files only.

> case 2:
>
> DBus-Event (dbus-event :post-blank 0 :post-affiliated 1455145 :mode
> nil :granularity element :cached t :parent (section (:begin 1179957 :
> end 1609350 :contents-begin 1179957 :contents-end 1609349 :
> robust-begin 1179957 :robust-end 1609347 :post-blank 1 :
> post-affiliated 1179957 :mode section :granularity element :cached t :
> parent (headline (:raw-value Old stuff :begin 1179945 :end 1609350 :
> pre-blank 0 :contents-begin 1179957 :contents-end 1609349 :
> robust-begin 1180109 :robust-end 1609347 :level 1 :priority nil :tags
> nil :todo-keyword nil :todo-type nil :post-blank 1 :footnote-section-p
> nil :archivedp nil :commentedp nil :post-affiliated 1179945 :
> ARCHIVE_TIME 2020-10-17 Sat 15:00 :ARCHIVE_FILE ~/work/worklog.org :
> ARCHIVE_OLPATH Scratch :ARCHIVE_CATEGORY worklog :title Old stuff :
> mode nil :granularity element :cached t :parent (org-data (:begin 1 :
> contents-begin 1 :contents-end 15432855 :end 15432856 :robust-begin 3 :
> robust-end 15432853 :post-blank 1 :post-affiliated 1 :path
> /home/kun/work/worklog.org_archive :mode org-data :CATEGORY worklog :
> cached t :org-element--cache-sync-key nil)) :
> org-element--cache-sync-key nil)) :org-element--cache-sync-key nil)) :
> org-element--cache-sync-key nil) [2 times]
> dbus-event-bus-name: D-Bus error: "Not a valid D-Bus event",
> (dbus-event :post-blank 0 :post-affiliated 1455145 :mode nil :
> granularity element :cached ...)

And here the same.

Could it be, that org-mode plays with events?

Best regards, Michael.

bug#70760: 29.3.50; core dumps when copy in other apps

[Kun Liu]

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

I did some more tests.

On fresh start, I open a new org file, say '/tmp/test.org'. I will
immediately see the following in *Messages* buffer. Opening other files (I
tried csv, py, txt, cpp, c, java) has no such effect.

(New file)
xd_add_watch: fd 14, write 2, enabled 0
xd_add_watch: fd 14, write 0, enabled 1
Fdbus__init_bus: Registered buses: ((:system . 23518017264452))
Fdbus__init_bus: Bus :system, Reference counter 2
Fdbus_message_internal: DBUS_MESSAGE_TYPE_METHOD_CALL :system
org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus AddMatch
dbus-call-method-handler
Fdbus_message_internal: Parameter1:
type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'
xd_signature: s
xd_append_arg: s
type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'
Fdbus_message_internal: Message sent: (:serial :system 2)
xd_retrieve_arg: s :1.492
xd_read_message_1: Event received: DBUS_MESSAGE_TYPE_SIGNAL 2
org.freedesktop.DBus :1.492 /org/freedesktop/DBus org.freedesktop.DBus
NameAcquired ((:string :1.492))
xd_read_message_1: Event received: DBUS_MESSAGE_TYPE_METHOD_RETURN 2
org.freedesktop.DBus :1.492 (null) (null) (null) nil
xd_read_message_1: Event stored: (:system 2 2 org.freedesktop.DBus :1.492
nil nil nil dbus-call-method-handler)
DBus-Event (dbus-event :system 2 2 org.freedesktop.DBus :1.492 nil nil nil
dbus-call-method-handler) [3 times]
Matching rule
"type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'"
created
xd_add_watch: fd 15, write 2, enabled 0
xd_add_watch: fd 15, write 0, enabled 1
Fdbus__init_bus: Registered buses: ((:session . 23518017267316) (:system .
23518017264452))
Fdbus__init_bus: Bus :session, Reference counter 2
Fdbus_message_internal: DBUS_MESSAGE_TYPE_METHOD_CALL :session
org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus AddMatch
dbus-call-method-handler
Fdbus_message_internal: Parameter1:
type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'
xd_signature: s
xd_append_arg: s
type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'
Fdbus_message_internal: Message sent: (:serial :session 2)
xd_retrieve_arg: s :1.1051
xd_read_message_1: Event received: DBUS_MESSAGE_TYPE_SIGNAL 2
org.freedesktop.DBus :1.1051 /org/freedesktop/DBus org.freedesktop.DBus
NameAcquired ((:string :1.1051))
xd_read_message_1: Event received: DBUS_MESSAGE_TYPE_METHOD_RETURN 2
org.freedesktop.DBus :1.1051 (null) (null) (null) nil
xd_read_message_1: Event stored: (:session 2 2 org.freedesktop.DBus :1.1051
nil nil nil dbus-call-method-handler)
DBus-Event (dbus-event :session 2 2 org.freedesktop.DBus :1.1051 nil nil
nil dbus-call-method-handler) [3 times]
Matching rule
"type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'"
created

On Wed, May 15, 2024 at 10:54 AM Michael Albinus <michael.albinus@gmx.de>
wrote:

> Kun Liu <kun.liu@gmail.com> writes:
>
> Hi,
>
> > Here is a couple of instances of what I saw in *Messages* right after
> > I was able to trigger the problem.
>
> So no messages from dbusbond.c, which is good for analysis: the events
> haven't benn inserted via the D-Bus system of your machine.
>
> > case 1:
> >
> > DBus-Event (dbus-event :post-blank 0 :post-affiliated 1455145 :mode
> > nil :granularity element :cached t :parent (section (:begin 1179957 :
> > end 1609350 :contents-begin 1179957 :contents-end 1609349 :
> > robust-begin 1179957 :robust-end 1609347 :post-blank 1 :
> > post-affiliated 1179957 :mode section :granularity element :cached t :
> > parent (headline (:raw-value Old stuff :begin 1179945 :end 1609350 :
> > pre-blank 0 :contents-begin 1179957 :contents-end 1609349 :
> > robust-begin 1180109 :robust-end 1609347 :level 1 :priority nil :tags
> > nil :todo-keyword nil :todo-type nil :post-blank 1 :footnote-section-p
> > nil :archivedp nil :commentedp nil :post-affiliated 1179945 :
> > ARCHIVE_TIME 2020-10-17 Sat 15:00 :ARCHIVE_FILE ~/work/worklog.org :
> > ARCHIVE_OLPATH Scratch :ARCHIVE_CATEGORY worklog :title Old stuff :
> > mode nil :granularity element :cached t :parent (org-data (:begin 1 :
> > contents-begin 1 :contents-end 15432855 :end 15432856 :robust-begin 3 :
> > robust-end 15432853 :post-blank 1 :post-affiliated 1 :path
> > /home/kun/work/worklog.org_archive :mode org-data :CATEGORY worklog :
> > cached t :org-element--cache-sync-key nil)) :
> > org-element--cache-sync-key nil)) :org-element--cache-sync-key nil)) :
> > org-element--cache-sync-key nil) [2 times]
> > Entering debugger...
> > DBus-Event (dbus-event x . make4ht)
> > funcall-interactively: Wrong type argument: listp, "make4ht"
>
> The :post-blank keyword exist in org/*.el files only.
>
> > case 2:
> >
> > DBus-Event (dbus-event :post-blank 0 :post-affiliated 1455145 :mode
> > nil :granularity element :cached t :parent (section (:begin 1179957 :
> > end 1609350 :contents-begin 1179957 :contents-end 1609349 :
> > robust-begin 1179957 :robust-end 1609347 :post-blank 1 :
> > post-affiliated 1179957 :mode section :granularity element :cached t :
> > parent (headline (:raw-value Old stuff :begin 1179945 :end 1609350 :
> > pre-blank 0 :contents-begin 1179957 :contents-end 1609349 :
> > robust-begin 1180109 :robust-end 1609347 :level 1 :priority nil :tags
> > nil :todo-keyword nil :todo-type nil :post-blank 1 :footnote-section-p
> > nil :archivedp nil :commentedp nil :post-affiliated 1179945 :
> > ARCHIVE_TIME 2020-10-17 Sat 15:00 :ARCHIVE_FILE ~/work/worklog.org :
> > ARCHIVE_OLPATH Scratch :ARCHIVE_CATEGORY worklog :title Old stuff :
> > mode nil :granularity element :cached t :parent (org-data (:begin 1 :
> > contents-begin 1 :contents-end 15432855 :end 15432856 :robust-begin 3 :
> > robust-end 15432853 :post-blank 1 :post-affiliated 1 :path
> > /home/kun/work/worklog.org_archive :mode org-data :CATEGORY worklog :
> > cached t :org-element--cache-sync-key nil)) :
> > org-element--cache-sync-key nil)) :org-element--cache-sync-key nil)) :
> > org-element--cache-sync-key nil) [2 times]
> > dbus-event-bus-name: D-Bus error: "Not a valid D-Bus event",
> > (dbus-event :post-blank 0 :post-affiliated 1455145 :mode nil :
> > granularity element :cached ...)
>
> And here the same.
>
> Could it be, that org-mode plays with events?
>
> Best regards, Michael.
>

[-- Attachment #2: Type: text/html, Size: 7744 bytes --]

bug#70760: 29.3.50; core dumps when copy in other apps

[Kun Liu]

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

I started dbus-monitor to monitor both session and system messages. Then I
repeated the test mentioned in the last message.

The relevant lines in the "dbus-monitor --system" output: (please note that
the dbus address is different from the previous test)
method call time=1715806663.121956 sender=:1.82 ->
destination=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus;
interface=org.freedesktop.DBus; member=Hello
method return time=1715806663.121973 sender=org.freedesktop.DBus ->
destination=:1.82 serial=1 reply_serial=1
   string ":1.82"
signal time=1715806663.121976 sender=org.freedesktop.DBus ->
destination=(null destination) serial=101 path=/org/freedesktop/DBus;
interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.82"
   string ""
   string ":1.82"
signal time=1715806663.121981 sender=org.freedesktop.DBus ->
destination=:1.82 serial=2 path=/org/freedesktop/DBus;
interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.82"
method call time=1715806663.130182 sender=:1.82 ->
destination=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus;
interface=org.freedesktop.DBus; member=AddMatch
   string
"type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'"
method return time=1715806663.130202 sender=org.freedesktop.DBus ->
destination=:1.82 serial=3 reply_serial=2
...
signal time=1715806675.545929 sender=org.freedesktop.DBus ->
destination=:1.82 serial=4 path=/org/freedesktop/DBus;
interface=org.freedesktop.DBus; member=NameLost
   string ":1.82"
signal time=1715806675.545978 sender=org.freedesktop.DBus ->
destination=(null destination) serial=102 path=/org/freedesktop/DBus;
interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.82"
   string ":1.82"
   string ""

The relevant lines in the "dbus-monitor" output:
method call time=1715806663.132226 sender=:1.177 ->
destination=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus;
interface=org.freedesktop.DBus; member=Hello
method return time=1715806663.132238 sender=org.freedesktop.DBus ->
destination=:1.177 serial=1 reply_serial=1
   string ":1.177"
signal time=1715806663.132242 sender=org.freedesktop.DBus ->
destination=(null destination) serial=704 path=/org/freedesktop/DBus;
interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.177"
   string ""
   string ":1.177"
signal time=1715806663.132246 sender=org.freedesktop.DBus ->
destination=:1.177 serial=2 path=/org/freedesktop/DBus;
interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.177"
method call time=1715806663.132256 sender=:1.153 ->
destination=org.freedesktop.DBus serial=657 path=/org/freedesktop/DBus;
interface=org.freedesktop.DBus; member=GetConnectionUnixProcessID
   string ":1.177"
method call time=1715806663.132987 sender=:1.177 ->
destination=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus;
interface=org.freedesktop.DBus; member=AddMatch
   string
"type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'"
method return time=1715806663.132998 sender=org.freedesktop.DBus ->
destination=:1.177 serial=3 reply_serial=2
signal time=1715806675.543269 sender=org.freedesktop.DBus ->
destination=:1.177 serial=4 path=/org/freedesktop/DBus;
interface=org.freedesktop.DBus; member=NameLost
   string ":1.177"
signal time=1715806675.543406 sender=org.freedesktop.DBus ->
destination=(null destination) serial=706 path=/org/freedesktop/DBus;
interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.177"
   string ":1.177"
   string ""

On Wed, May 15, 2024 at 11:25 AM Kun Liu <kun.liu@gmail.com> wrote:

> I did some more tests.
>
> On fresh start, I open a new org file, say '/tmp/test.org'. I will
> immediately see the following in *Messages* buffer. Opening other files (I
> tried csv, py, txt, cpp, c, java) has no such effect.
>
> (New file)
> xd_add_watch: fd 14, write 2, enabled 0
> xd_add_watch: fd 14, write 0, enabled 1
> Fdbus__init_bus: Registered buses: ((:system . 23518017264452))
> Fdbus__init_bus: Bus :system, Reference counter 2
> Fdbus_message_internal: DBUS_MESSAGE_TYPE_METHOD_CALL :system
> org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus AddMatch
> dbus-call-method-handler
> Fdbus_message_internal: Parameter1:
> type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'
> xd_signature: s
> xd_append_arg: s
> type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'
> Fdbus_message_internal: Message sent: (:serial :system 2)
> xd_retrieve_arg: s :1.492
> xd_read_message_1: Event received: DBUS_MESSAGE_TYPE_SIGNAL 2
> org.freedesktop.DBus :1.492 /org/freedesktop/DBus org.freedesktop.DBus
> NameAcquired ((:string :1.492))
> xd_read_message_1: Event received: DBUS_MESSAGE_TYPE_METHOD_RETURN 2
> org.freedesktop.DBus :1.492 (null) (null) (null) nil
> xd_read_message_1: Event stored: (:system 2 2 org.freedesktop.DBus :1.492
> nil nil nil dbus-call-method-handler)
> DBus-Event (dbus-event :system 2 2 org.freedesktop.DBus :1.492 nil nil nil
> dbus-call-method-handler) [3 times]
> Matching rule
> "type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'"
> created
> xd_add_watch: fd 15, write 2, enabled 0
> xd_add_watch: fd 15, write 0, enabled 1
> Fdbus__init_bus: Registered buses: ((:session . 23518017267316) (:system .
> 23518017264452))
> Fdbus__init_bus: Bus :session, Reference counter 2
> Fdbus_message_internal: DBUS_MESSAGE_TYPE_METHOD_CALL :session
> org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus AddMatch
> dbus-call-method-handler
> Fdbus_message_internal: Parameter1:
> type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'
> xd_signature: s
> xd_append_arg: s
> type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'
> Fdbus_message_internal: Message sent: (:serial :session 2)
> xd_retrieve_arg: s :1.1051
> xd_read_message_1: Event received: DBUS_MESSAGE_TYPE_SIGNAL 2
> org.freedesktop.DBus :1.1051 /org/freedesktop/DBus org.freedesktop.DBus
> NameAcquired ((:string :1.1051))
> xd_read_message_1: Event received: DBUS_MESSAGE_TYPE_METHOD_RETURN 2
> org.freedesktop.DBus :1.1051 (null) (null) (null) nil
> xd_read_message_1: Event stored: (:session 2 2 org.freedesktop.DBus
> :1.1051 nil nil nil dbus-call-method-handler)
> DBus-Event (dbus-event :session 2 2 org.freedesktop.DBus :1.1051 nil nil
> nil dbus-call-method-handler) [3 times]
> Matching rule
> "type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'"
> created
>
> On Wed, May 15, 2024 at 10:54 AM Michael Albinus <michael.albinus@gmx.de>
> wrote:
>
>> Kun Liu <kun.liu@gmail.com> writes:
>>
>> Hi,
>>
>> > Here is a couple of instances of what I saw in *Messages* right after
>> > I was able to trigger the problem.
>>
>> So no messages from dbusbond.c, which is good for analysis: the events
>> haven't benn inserted via the D-Bus system of your machine.
>>
>> > case 1:
>> >
>> > DBus-Event (dbus-event :post-blank 0 :post-affiliated 1455145 :mode
>> > nil :granularity element :cached t :parent (section (:begin 1179957 :
>> > end 1609350 :contents-begin 1179957 :contents-end 1609349 :
>> > robust-begin 1179957 :robust-end 1609347 :post-blank 1 :
>> > post-affiliated 1179957 :mode section :granularity element :cached t :
>> > parent (headline (:raw-value Old stuff :begin 1179945 :end 1609350 :
>> > pre-blank 0 :contents-begin 1179957 :contents-end 1609349 :
>> > robust-begin 1180109 :robust-end 1609347 :level 1 :priority nil :tags
>> > nil :todo-keyword nil :todo-type nil :post-blank 1 :footnote-section-p
>> > nil :archivedp nil :commentedp nil :post-affiliated 1179945 :
>> > ARCHIVE_TIME 2020-10-17 Sat 15:00 :ARCHIVE_FILE ~/work/worklog.org :
>> > ARCHIVE_OLPATH Scratch :ARCHIVE_CATEGORY worklog :title Old stuff :
>> > mode nil :granularity element :cached t :parent (org-data (:begin 1 :
>> > contents-begin 1 :contents-end 15432855 :end 15432856 :robust-begin 3 :
>> > robust-end 15432853 :post-blank 1 :post-affiliated 1 :path
>> > /home/kun/work/worklog.org_archive :mode org-data :CATEGORY worklog :
>> > cached t :org-element--cache-sync-key nil)) :
>> > org-element--cache-sync-key nil)) :org-element--cache-sync-key nil)) :
>> > org-element--cache-sync-key nil) [2 times]
>> > Entering debugger...
>> > DBus-Event (dbus-event x . make4ht)
>> > funcall-interactively: Wrong type argument: listp, "make4ht"
>>
>> The :post-blank keyword exist in org/*.el files only.
>>
>> > case 2:
>> >
>> > DBus-Event (dbus-event :post-blank 0 :post-affiliated 1455145 :mode
>> > nil :granularity element :cached t :parent (section (:begin 1179957 :
>> > end 1609350 :contents-begin 1179957 :contents-end 1609349 :
>> > robust-begin 1179957 :robust-end 1609347 :post-blank 1 :
>> > post-affiliated 1179957 :mode section :granularity element :cached t :
>> > parent (headline (:raw-value Old stuff :begin 1179945 :end 1609350 :
>> > pre-blank 0 :contents-begin 1179957 :contents-end 1609349 :
>> > robust-begin 1180109 :robust-end 1609347 :level 1 :priority nil :tags
>> > nil :todo-keyword nil :todo-type nil :post-blank 1 :footnote-section-p
>> > nil :archivedp nil :commentedp nil :post-affiliated 1179945 :
>> > ARCHIVE_TIME 2020-10-17 Sat 15:00 :ARCHIVE_FILE ~/work/worklog.org :
>> > ARCHIVE_OLPATH Scratch :ARCHIVE_CATEGORY worklog :title Old stuff :
>> > mode nil :granularity element :cached t :parent (org-data (:begin 1 :
>> > contents-begin 1 :contents-end 15432855 :end 15432856 :robust-begin 3 :
>> > robust-end 15432853 :post-blank 1 :post-affiliated 1 :path
>> > /home/kun/work/worklog.org_archive :mode org-data :CATEGORY worklog :
>> > cached t :org-element--cache-sync-key nil)) :
>> > org-element--cache-sync-key nil)) :org-element--cache-sync-key nil)) :
>> > org-element--cache-sync-key nil) [2 times]
>> > dbus-event-bus-name: D-Bus error: "Not a valid D-Bus event",
>> > (dbus-event :post-blank 0 :post-affiliated 1455145 :mode nil :
>> > granularity element :cached ...)
>>
>> And here the same.
>>
>> Could it be, that org-mode plays with events?
>>
>> Best regards, Michael.
>>
>

[-- Attachment #2: Type: text/html, Size: 12302 bytes --]

bug#70760: 29.3.50; core dumps when copy in other apps

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Kun Liu <kun.liu@gmail.com> writes:

Hi,

> I did some more tests.

Thanks.

> On fresh start, I open a new org file, say '/tmp/test.org'. I will
> immediately see the following in *Messages* buffer. Opening other
> files (I tried csv, py, txt, cpp, c, java) has no such effect.

These traces come from dbusbind.c. They cover the D-Bus initialization
from Emacs POV, registering for signals and alike.

> xd_add_watch: fd 14, write 2, enabled 0
> xd_add_watch: fd 14, write 0, enabled 1
> Fdbus__init_bus: Registered buses: ((:system . 23518017264452))
> Fdbus__init_bus: Bus :system, Reference counter 2
> Fdbus_message_internal: DBUS_MESSAGE_TYPE_METHOD_CALL :system
> org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus
> AddMatch dbus-call-method-handler
> Fdbus_message_internal: Parameter1:
> type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'
>
> xd_signature: s
> xd_append_arg: s
> type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'
>
> Fdbus_message_internal: Message sent: (:serial :system 2)

This registers for signals from the :system bus, for calling methods.

> xd_retrieve_arg: s :1.492
> xd_read_message_1: Event received: DBUS_MESSAGE_TYPE_SIGNAL 2
> org.freedesktop.DBus :1.492 /org/freedesktop/DBus org.freedesktop.DBus
> NameAcquired ((:string :1.492))
> xd_read_message_1: Event received: DBUS_MESSAGE_TYPE_METHOD_RETURN 2
> org.freedesktop.DBus :1.492 (null) (null) (null) nil
> xd_read_message_1: Event stored: (:system 2 2 org.freedesktop.DBus :
> 1.492 nil nil nil dbus-call-method-handler)
> DBus-Event (dbus-event :system 2 2 org.freedesktop.DBus :1.492 nil nil
> nil dbus-call-method-handler) [3 times]
> Matching rule
> "type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'"
> created

This is the confirmation from D-Bus, that the registration was successful.

> xd_add_watch: fd 15, write 2, enabled 0
> xd_add_watch: fd 15, write 0, enabled 1
> Fdbus__init_bus: Registered buses: ((:session . 23518017267316)
> (:system . 23518017264452))
> Fdbus__init_bus: Bus :session, Reference counter 2
> Fdbus_message_internal: DBUS_MESSAGE_TYPE_METHOD_CALL :session
> org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus
> AddMatch dbus-call-method-handler
> Fdbus_message_internal: Parameter1:
> type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'
>
> xd_signature: s
> xd_append_arg: s
> type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'
>
> Fdbus_message_internal: Message sent: (:serial :session 2)

This is the similar registration for the :session bus.

> xd_retrieve_arg: s :1.1051
> xd_read_message_1: Event received: DBUS_MESSAGE_TYPE_SIGNAL 2
> org.freedesktop.DBus :1.1051 /org/freedesktop/DBus
> org.freedesktop.DBus NameAcquired ((:string :1.1051))
> xd_read_message_1: Event received: DBUS_MESSAGE_TYPE_METHOD_RETURN 2
> org.freedesktop.DBus :1.1051 (null) (null) (null) nil
> xd_read_message_1: Event stored: (:session 2 2 org.freedesktop.DBus :
> 1.1051 nil nil nil dbus-call-method-handler)
> DBus-Event (dbus-event :session 2 2 org.freedesktop.DBus :1.1051 nil
> nil nil dbus-call-method-handler) [3 times]
> Matching rule
> "type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'"
> created

And this is the corresponding reply from D-Bus.

Everything normal, this initialization happens always. I guess you'll
see it also when starting Emacs with another file type but .org.

Best regards, Michael.

bug#70760: 29.3.50; core dumps when copy in other apps

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Kun Liu <kun.liu@gmail.com> writes:

Hi,

> I started dbus-monitor to monitor both session and system messages.
> Then I repeated the test mentioned in the last message.
>
> The relevant lines in the "dbus-monitor --system" output: (please note
> that the dbus address is different from the previous test)

Yep. Emacs gets a new D-Bus address every new start, it is :1.82 this
case.

> method call time=1715806663.121956 sender=:1.82 ->
> destination=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus;
> interface=org.freedesktop.DBus; member=Hello
> method return time=1715806663.121973 sender=org.freedesktop.DBus ->
> destination=:1.82 serial=1 reply_serial=1
>    string ":1.82"

Emacs sys "Hello" to D-Bus.

> signal time=1715806663.121976 sender=org.freedesktop.DBus ->
> destination=(null destination) serial=101 path=/org/freedesktop/DBus;
> interface=org.freedesktop.DBus; member=NameOwnerChanged
>    string ":1.82"
>    string ""
>    string ":1.82"
> signal time=1715806663.121981 sender=org.freedesktop.DBus ->
> destination=:1.82 serial=2 path=/org/freedesktop/DBus;
> interface=org.freedesktop.DBus; member=NameAcquired
>    string ":1.82"

D-Bus replies two signals, saying that it understood the "Hello", and
that it has registered the service with unique name :1.82.

> method call time=1715806663.130182 sender=:1.82 ->
> destination=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus;
> interface=org.freedesktop.DBus; member=AddMatch
>    string
> "type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'"
>
> method return time=1715806663.130202 sender=org.freedesktop.DBus ->
> destination=:1.82 serial=3 reply_serial=2

Emacs registers for signals.

> ...
> signal time=1715806675.545929 sender=org.freedesktop.DBus ->
> destination=:1.82 serial=4 path=/org/freedesktop/DBus;
> interface=org.freedesktop.DBus; member=NameLost
>    string ":1.82"
> signal time=1715806675.545978 sender=org.freedesktop.DBus ->
> destination=(null destination) serial=102 path=/org/freedesktop/DBus;
> interface=org.freedesktop.DBus; member=NameOwnerChanged
>    string ":1.82"
>    string ":1.82"
>    string ""

This is very likely the time you have stopped Emacs, and D-Bus
unregisters its unique name, therefore.

> The relevant lines in the "dbus-monitor" output:

The look very similar to the system bus output. Here, Emacs has the
unique name :1.177.

> method call time=1715806663.132256 sender=:1.153 ->
> destination=org.freedesktop.DBus serial=657
> path=/org/freedesktop/DBus; interface=org.freedesktop.DBus;
> member=GetConnectionUnixProcessID
>    string ":1.177"

This is an additional call from service 1.153, which wants to know the
Emacs pid. We can ignore it.

Everything normal, and not related to the problem I believe.

Best regards, Michael.

bug#70760: 29.3.50; core dumps when copy in other apps

[Kun Liu]

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

Thanks much, Michael, for the detailed explanation.

I spent more time on this issue. I watched closely both "dbus-monitor
--system" and "dbus-monitor" outputs, while trying to replicate the issue
in Emacs. It appears that just as you said, when Emacs reported invalid
dbus events, which crashes Emacs sometimes, dbus-monitor outputs never
showed any messages immediately preceding or following the error.

Which really begs the question, if dbus did not have any messages for Emacs
at the time, why did Emacs think there was a message for it?

On Thu, May 16, 2024 at 2:20 AM Michael Albinus <michael.albinus@gmx.de>
wrote:

> Kun Liu <kun.liu@gmail.com> writes:
>
> Hi,
>
> > I started dbus-monitor to monitor both session and system messages.
> > Then I repeated the test mentioned in the last message.
> >
> > The relevant lines in the "dbus-monitor --system" output: (please note
> > that the dbus address is different from the previous test)
>
> Yep. Emacs gets a new D-Bus address every new start, it is :1.82 this
> case.
>
> > method call time=1715806663.121956 sender=:1.82 ->
> > destination=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus;
> > interface=org.freedesktop.DBus; member=Hello
> > method return time=1715806663.121973 sender=org.freedesktop.DBus ->
> > destination=:1.82 serial=1 reply_serial=1
> >    string ":1.82"
>
> Emacs sys "Hello" to D-Bus.
>
> > signal time=1715806663.121976 sender=org.freedesktop.DBus ->
> > destination=(null destination) serial=101 path=/org/freedesktop/DBus;
> > interface=org.freedesktop.DBus; member=NameOwnerChanged
> >    string ":1.82"
> >    string ""
> >    string ":1.82"
> > signal time=1715806663.121981 sender=org.freedesktop.DBus ->
> > destination=:1.82 serial=2 path=/org/freedesktop/DBus;
> > interface=org.freedesktop.DBus; member=NameAcquired
> >    string ":1.82"
>
> D-Bus replies two signals, saying that it understood the "Hello", and
> that it has registered the service with unique name :1.82.
>
> > method call time=1715806663.130182 sender=:1.82 ->
> > destination=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus;
> > interface=org.freedesktop.DBus; member=AddMatch
> >    string
> >
> "type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'"
> >
> > method return time=1715806663.130202 sender=org.freedesktop.DBus ->
> > destination=:1.82 serial=3 reply_serial=2
>
> Emacs registers for signals.
>
> > ...
> > signal time=1715806675.545929 sender=org.freedesktop.DBus ->
> > destination=:1.82 serial=4 path=/org/freedesktop/DBus;
> > interface=org.freedesktop.DBus; member=NameLost
> >    string ":1.82"
> > signal time=1715806675.545978 sender=org.freedesktop.DBus ->
> > destination=(null destination) serial=102 path=/org/freedesktop/DBus;
> > interface=org.freedesktop.DBus; member=NameOwnerChanged
> >    string ":1.82"
> >    string ":1.82"
> >    string ""
>
> This is very likely the time you have stopped Emacs, and D-Bus
> unregisters its unique name, therefore.
>
> > The relevant lines in the "dbus-monitor" output:
>
> The look very similar to the system bus output. Here, Emacs has the
> unique name :1.177.
>
> > method call time=1715806663.132256 sender=:1.153 ->
> > destination=org.freedesktop.DBus serial=657
> > path=/org/freedesktop/DBus; interface=org.freedesktop.DBus;
> > member=GetConnectionUnixProcessID
> >    string ":1.177"
>
> This is an additional call from service 1.153, which wants to know the
> Emacs pid. We can ignore it.
>
> Everything normal, and not related to the problem I believe.
>
> Best regards, Michael.
>

[-- Attachment #2: Type: text/html, Size: 4641 bytes --]

bug#70760: 29.3.50; core dumps when copy in other apps

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Kun Liu <kun.liu@gmail.com> writes:

Hi,

> I spent more time on this issue. I watched closely both "dbus-monitor -
> -system" and "dbus-monitor" outputs, while trying to replicate the
> issue in Emacs. It appears that just as you said, when Emacs reported
> invalid dbus events, which crashes Emacs sometimes, dbus-monitor
> outputs never showed any messages immediately preceding or following
> the error.

This is another evidence why I believe the invalid D-Bus event hasn't
been injected to Emacs from external. It is something which happens in
Emacs internally, and that's why I believe we cannot simply ignore
bad-formed D-Bus events.

> Which really begs the question, if dbus did not have any messages for
> Emacs at the time, why did Emacs think there was a message for it?

Well, look at the architecture.

Emacs id connected to both the system and session D-Bus via a file
descriptor. From time to time Emacs receives events via this way in
xd_read_message_1. This will be transformed into a "Lispy event", a list
which starts with the symbol `dbus-event'. Something like

--8<---------------cut here---------------start------------->8---
(dbus-event :system 2 2 org.freedesktop.DBus :1.492 nil nil
 nil dbus-call-method-handler)
--8<---------------cut here---------------end--------------->8---

This "Lispy event" will be stored in Emacs' input event queue, see line
1759 or 1803 in dbusbind.c. There's no further action in dbusbind.c wrt
to this event afterwards,

The Emacs main loop checks periodically the input event queue. If it
detects something, it takes action. Often it is just a keyboard
event. But there are also special events like the D-Bus event. For them,
the variable `special-event-map', checking first for the event type, and
call the respective handler then. For D-Bus events, this would be the
call (dbus-handle-event event), which we have seen in your backtraces.

But what if an event is added to the input event queue, which has an
arbitrary format? Or an existing event has been modified? It could look
like a D-Bus event (the car of the event is `dbus-event'), but the rest
of the list is random. It must not come via the dbusevent.c mechanism
I've explained above, anybody can push such an event onto then input
event queue. But I have no idea how to debug this.

Best regards, Michael.

bug#70760: 29.3.50; core dumps when copy in other apps

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Eli Zaretskii <eliz@gnu.org>,  70760@debbugs.gnu.org
> Date: Fri, 17 May 2024 18:23:46 +0200
> 
> But what if an event is added to the input event queue, which has an
> arbitrary format? Or an existing event has been modified? It could look
> like a D-Bus event (the car of the event is `dbus-event'), but the rest
> of the list is random. It must not come via the dbusevent.c mechanism
> I've explained above, anybody can push such an event onto then input
> event queue. But I have no idea how to debug this.

Which file descriptors do we listen to, apart of sub-processes and
inotify?

bug#70760: 29.3.50; core dumps when copy in other apps

[Kun Liu]

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

I've tried various combinations of Debian11/12, Emacs 27/28/29/30,
native-compilation yes/no. This behavior seems to be always present.

On the other hand, based on all the tests I have done, it appears that this
issue happens when org-mode is loaded. I will run more tests and report
back if I see it happen without org-mode.

On Fri, May 17, 2024 at 10:34 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Michael Albinus <michael.albinus@gmx.de>
> > Cc: Eli Zaretskii <eliz@gnu.org>,  70760@debbugs.gnu.org
> > Date: Fri, 17 May 2024 18:23:46 +0200
> >
> > But what if an event is added to the input event queue, which has an
> > arbitrary format? Or an existing event has been modified? It could look
> > like a D-Bus event (the car of the event is `dbus-event'), but the rest
> > of the list is random. It must not come via the dbusevent.c mechanism
> > I've explained above, anybody can push such an event onto then input
> > event queue. But I have no idea how to debug this.
>
> Which file descriptors do we listen to, apart of sub-processes and
> inotify?
>

[-- Attachment #2: Type: text/html, Size: 1628 bytes --]

bug#70760: 29.3.50; core dumps when copy in other apps

[Kun Liu]

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

Just a quick update: I went through my .emacs line by line and was able to
find the culprit.

After I commented out "(follow-mode t)", Emacs has been running fine for a
few hours now.

It appears the combination of org-mode, follow-mode in Emacs 27-30 running
in a Debian 11/12 VM in VirtualBox 6/7 on a Windows 11 host, and a copy
operation on the host, sometimes causes problems.

Thank you, Eli and Michael, for your help. I really appreciate it.

On Fri, May 17, 2024 at 1:43 PM Kun Liu <kun.liu@gmail.com> wrote:

> I've tried various combinations of Debian11/12, Emacs 27/28/29/30,
> native-compilation yes/no. This behavior seems to be always present.
>
> On the other hand, based on all the tests I have done, it appears that
> this issue happens when org-mode is loaded. I will run more tests and
> report back if I see it happen without org-mode.
>
> On Fri, May 17, 2024 at 10:34 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > From: Michael Albinus <michael.albinus@gmx.de>
>> > Cc: Eli Zaretskii <eliz@gnu.org>,  70760@debbugs.gnu.org
>> > Date: Fri, 17 May 2024 18:23:46 +0200
>> >
>> > But what if an event is added to the input event queue, which has an
>> > arbitrary format? Or an existing event has been modified? It could look
>> > like a D-Bus event (the car of the event is `dbus-event'), but the rest
>> > of the list is random. It must not come via the dbusevent.c mechanism
>> > I've explained above, anybody can push such an event onto then input
>> > event queue. But I have no idea how to debug this.
>>
>> Which file descriptors do we listen to, apart of sub-processes and
>> inotify?
>>
>

[-- Attachment #2: Type: text/html, Size: 2526 bytes --]

bug#70760: 29.3.50; core dumps when copy in other apps

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> But what if an event is added to the input event queue, which has an
>> arbitrary format? Or an existing event has been modified? It could look
>> like a D-Bus event (the car of the event is `dbus-event'), but the rest
>> of the list is random. It must not come via the dbusevent.c mechanism
>> I've explained above, anybody can push such an event onto then input
>> event queue. But I have no idea how to debug this.
>
> Which file descriptors do we listen to, apart of sub-processes and
> inotify?

See xd_add_watch. xd_find_watch_fd returns the file descriptor
reponsible for a given D-Bus connection (this is a bus like the system
bus, the session bus, or a private bus). This file descriptor is added
to Emacs via add_write_fd and add_read_fd, using the callback
xd_read_queued_messages. So it might look like a subprocess ...

Best regards, Michael.

bug#70760: 29.3.50; core dumps when copy in other apps

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: kun.liu@gmail.com,  70760@debbugs.gnu.org
> Date: Sat, 18 May 2024 12:32:29 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> Hi Eli,
> 
> >> But what if an event is added to the input event queue, which has an
> >> arbitrary format? Or an existing event has been modified? It could look
> >> like a D-Bus event (the car of the event is `dbus-event'), but the rest
> >> of the list is random. It must not come via the dbusevent.c mechanism
> >> I've explained above, anybody can push such an event onto then input
> >> event queue. But I have no idea how to debug this.
> >
> > Which file descriptors do we listen to, apart of sub-processes and
> > inotify?
> 
> See xd_add_watch. xd_find_watch_fd returns the file descriptor
> reponsible for a given D-Bus connection (this is a bus like the system
> bus, the session bus, or a private bus). This file descriptor is added
> to Emacs via add_write_fd and add_read_fd, using the callback
> xd_read_queued_messages. So it might look like a subprocess ...

You are saying that output of some subprocess could be interpreted as
D-Bus event?  How do we know which inputs to try to interpret as D-Bus
events?  IOW, can you hypothesize how could we take some non-D-Bus
input and end up interpreting it as D-Bus?

bug#70760: 29.3.50; core dumps when copy in other apps

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> See xd_add_watch. xd_find_watch_fd returns the file descriptor
>> reponsible for a given D-Bus connection (this is a bus like the system
>> bus, the session bus, or a private bus). This file descriptor is added
>> to Emacs via add_write_fd and add_read_fd, using the callback
>> xd_read_queued_messages. So it might look like a subprocess ...
>
> You are saying that output of some subprocess could be interpreted as
> D-Bus event?  How do we know which inputs to try to interpret as D-Bus
> events?  IOW, can you hypothesize how could we take some non-D-Bus
> input and end up interpreting it as D-Bus?

No. I'm saying that dbusbind.c uses add_write_fd and add_read_fd, which
are defined in process.c.

I don't believe that file descriptors of other subprocesses will provide
data for dbusbind.c. The registered file descriptors for D-Bus use the
callback xd_read_queued_messages, and only this callback reads the data
from the file descriptors, and generates D-Bus events.

This looks stable to me, and this architecture exists for many years.

Best regards, Michael.

bug#70760: 29.3.50; core dumps when copy in other apps

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: kun.liu@gmail.com,  70760@debbugs.gnu.org
> Date: Sat, 18 May 2024 13:54:24 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > You are saying that output of some subprocess could be interpreted as
> > D-Bus event?  How do we know which inputs to try to interpret as D-Bus
> > events?  IOW, can you hypothesize how could we take some non-D-Bus
> > input and end up interpreting it as D-Bus?
> 
> No. I'm saying that dbusbind.c uses add_write_fd and add_read_fd, which
> are defined in process.c.
> 
> I don't believe that file descriptors of other subprocesses will provide
> data for dbusbind.c. The registered file descriptors for D-Bus use the
> callback xd_read_queued_messages, and only this callback reads the data
> from the file descriptors, and generates D-Bus events.
> 
> This looks stable to me, and this architecture exists for many years.

OK.  So how could a non-D-Bus event end up being interpreted as a
D-Bus event?  Can we arrange for some breakpoints or watchpoints to
try to catch these inputs on their way to being interpreted as D-Bus
events, so that we could try figuring out where did those inputs come
from?

The only hint we have until now is that this happens when copying
stuff from other applications.  Does that ring any bells or suggest
any ideas?

bug#70760: 29.3.50; core dumps when copy in other apps

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> OK.  So how could a non-D-Bus event end up being interpreted as a
> D-Bus event?

We see calls of dbus-event-handler in the backtrace shown by Kun
Liu. This can happen only via special-mode-map, when an event is
detected in the event queue, which is a list with the car being the
symbol `dbus-event'. The rest of the event is not checked at this point,
the event is checked for D-Bus properness in the handler.

We have also seen by the tests of Kun Liu, that no external D-Bus event
has arrived at this time. So I guess either such an invalid D-Bus event
has been pushed by another package to the event queue, or an existing
valid event has been modified that the car is the symbol `dbus-event'.

> Can we arrange for some breakpoints or watchpoints to
> try to catch these inputs on their way to being interpreted as D-Bus
> events, so that we could try figuring out where did those inputs come
> from?

No idea. The backtrace shown by Kun Liu starts with the call of
dbus-event-handler. I have no idea how to watch the event queue - this
is out of my knowledge.

> The only hint we have until now is that this happens when copying
> stuff from other applications.  Does that ring any bells or suggest
> any ideas?

Not for me. What I have seen is that xd_add_watch calls add_read_fd. But
in process.c, there is also the function add_non_keyboard_read_fd. I
have no idea what's the difference, but this function must exist for a
reason. Would it make sense to use this function instead? Just a wild
guess.

Best regards, Michael.

bug#70760: 29.3.50; core dumps when copy in other apps

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: kun.liu@gmail.com,  70760@debbugs.gnu.org
> Date: Sat, 18 May 2024 18:55:51 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > OK.  So how could a non-D-Bus event end up being interpreted as a
> > D-Bus event?
> 
> We see calls of dbus-event-handler in the backtrace shown by Kun
> Liu. This can happen only via special-mode-map, when an event is
> detected in the event queue, which is a list with the car being the
> symbol `dbus-event'. The rest of the event is not checked at this point,
> the event is checked for D-Bus properness in the handler.
> 
> We have also seen by the tests of Kun Liu, that no external D-Bus event
> has arrived at this time. So I guess either such an invalid D-Bus event
> has been pushed by another package to the event queue, or an existing
> valid event has been modified that the car is the symbol `dbus-event'.

But the only place in Emacs that generates dbus-event events is
dbusbind.c, right?  So in that case, the first suspect is some Lisp
package that pushes such events onto the Emacs event queue, do you
agree?

> > The only hint we have until now is that this happens when copying
> > stuff from other applications.  Does that ring any bells or suggest
> > any ideas?
> 
> Not for me. What I have seen is that xd_add_watch calls add_read_fd. But
> in process.c, there is also the function add_non_keyboard_read_fd. I
> have no idea what's the difference, but this function must exist for a
> reason. Would it make sense to use this function instead? Just a wild
> guess.

Yes, the descriptors we use to read sub-process output are
non-keyboard descriptors.  But as far as I understand what you say,
there's no way for those descriptors to generate dbus-event events.

bug#70760: 29.3.50; core dumps when copy in other apps

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> But the only place in Emacs that generates dbus-event events is
> dbusbind.c, right?  So in that case, the first suspect is some Lisp
> package that pushes such events onto the Emacs event queue, do you
> agree?

I agree, the Lispy D-Bus event should be generated only in dbusbind.c.

I've checked Emacs proper (lisp/ subdirectory), GNU ELPA and NonGNU ELPA
for the string "dbus-event". Obviously, it is contained in dbus.el. In
helm-core.el and tramp-gvfs.el, `dbus-event' is added to
`while-no-input-ignore-events'. In notifications.el, secrets.el,
tramp-gvfs.el and zeroconf.el accessor funtions of the `dbus-event'
structure are used. None of this looks strange to me.

>> Not for me. What I have seen is that xd_add_watch calls add_read_fd. But
>> in process.c, there is also the function add_non_keyboard_read_fd. I
>> have no idea what's the difference, but this function must exist for a
>> reason. Would it make sense to use this function instead? Just a wild
>> guess.
>
> Yes, the descriptors we use to read sub-process output are
> non-keyboard descriptors.  But as far as I understand what you say,
> there's no way for those descriptors to generate dbus-event events.

Yes.

Best regards, Michael.

bug#70760: 29.3.50; core dumps when copy in other apps

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: kun.liu@gmail.com,  70760@debbugs.gnu.org
> Date: Sat, 18 May 2024 20:22:21 +0200
> 
> > But the only place in Emacs that generates dbus-event events is
> > dbusbind.c, right?  So in that case, the first suspect is some Lisp
> > package that pushes such events onto the Emacs event queue, do you
> > agree?
> 
> I agree, the Lispy D-Bus event should be generated only in dbusbind.c.
> 
> I've checked Emacs proper (lisp/ subdirectory), GNU ELPA and NonGNU ELPA
> for the string "dbus-event". Obviously, it is contained in dbus.el. In
> helm-core.el and tramp-gvfs.el, `dbus-event' is added to
> `while-no-input-ignore-events'. In notifications.el, secrets.el,
> tramp-gvfs.el and zeroconf.el accessor funtions of the `dbus-event'
> structure are used. None of this looks strange to me.

OK, I will try to look for some way of catching these events when they
enter the input queue.