bug#45277: D-Bus crashes and DND errors

bug#45277: D-Bus crashes and DND errors

[Juri Linkov]

Sometimes DND causes just errors, sometimes D-BUS events cause Emacs crashes.

Here is an example of DND errors when debug-on-error is enabled:

Debugger entered--Lisp error: (error "Bad data in VALUES, must be number, cons or string")
  x-send-client-message(#<frame emacs@localhost 0x555556182a40> 21062611 #<frame emacs@localhost 0x555556182a40> "XdndStatus" 32 (62914762 0 ((+ -1) . 1) 0 0))
  x-dnd-handle-xdnd((drag-n-drop (#<frame emacs@localhost 0x555556182a40> nil (854 . 0) 0) ["XdndPosition" #<frame emacs@localhost 0x555556182a40> 32 [21062611 0 55967771 54687100 550]]) #<frame emacs@localhost 0x555556182a40> #<frame emacs@localhost 0x555556182a40> "XdndPosition" 32 [21062611 0 55967771 54687100 550])
  x-dnd-handle-drag-n-drop-event((drag-n-drop (#<frame emacs@localhost 0x555556182a40> nil (854 . 0) 0) ["XdndPosition" #<frame emacs@localhost 0x555556182a40> 32 [21062611 0 55967771 54687100 550]]))
  funcall-interactively(x-dnd-handle-drag-n-drop-event (drag-n-drop (#<frame emacs@localhost 0x555556182a40> nil (854 . 0) 0) ["XdndPosition" #<frame emacs@localhost 0x555556182a40> 32 [21062611 0 55967771 54687100 550]]))
  call-interactively(x-dnd-handle-drag-n-drop-event nil [(drag-n-drop (#<frame emacs@localhost 0x555556182a40> nil (854 . 0) 0) ["XdndPosition" #<frame emacs@localhost 0x555556182a40> 32 [21062611 0 55967771 54687100 550]])])
  command-execute(x-dnd-handle-drag-n-drop-event nil [(drag-n-drop (#<frame emacs@localhost 0x555556182a40> nil (854 . 0) 0) ["XdndPosition" #<frame emacs@localhost 0x555556182a40> 32 [21062611 0 55967771 54687100 550]])] t)

What is worse are sporadic crashes by dbus-handle-event:

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
print_preprocess (obj=obj@entry=XIL(0x55556462e080)) at lisp.h:2204
2204	  return XSYMBOL (sym)->u.s.interned != SYMBOL_UNINTERNED;
(gdb) bt
#0  print_preprocess (obj=obj@entry=XIL(0x55556462e080)) at lisp.h:2204
#1  0x000055555572f234 in print (obj=XIL(0x55556462e080), printcharfun=XIL(0x30), escapeflag=<optimized out>) at print.c:1126
#2  0x000055555572f702 in Fprin1 (object=XIL(0x55556462e080), printcharfun=<optimized out>) at print.c:651
#3  0x0000555555730895 in print_error_message (data=<optimized out>, data@entry=XIL(0x555558492423), stream=stream@entry=XIL(0x30), context=<optimized out>, caller=caller@entry=XIL(0x2aaa9c29dce0)) at print.c:977
#4  0x0000555555692547 in Fcommand_error_default_function (data=XIL(0x555558492423), context=XIL(0x7ffff1c52674), signal=XIL(0x2aaa9c29dce0)) at lisp.h:1564
#5  0x000055555570fa9b in Ffuncall (nargs=4, args=0x7fffffffc050) at lisp.h:2081
#6  0x0000555555711b28 in Fapply (nargs=2, args=0x7fffffffc168) at eval.c:2509
#7  0x000055555570fa9b in Ffuncall (nargs=3, args=args@entry=0x7fffffffc160) at lisp.h:2081
#8  0x000055555574cb54 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
#9  0x000055555570f9d7 in Ffuncall (nargs=4, args=0x7fffffffc430) at eval.c:2893
#10 0x000055555570fc38 in call3 (fn=<optimized out>, arg1=arg1@entry=XIL(0x555558492423), arg2=<optimized out>, arg3=arg3@entry=XIL(0x2aaa9c29dce0)) at eval.c:2753
#11 0x00005555556962e6 in cmd_error_internal (data=data@entry=XIL(0x555558492423), context=context@entry=0x7fffffffc490 "") at lisp.h:3910
#12 0x000055555569642b in cmd_error (data=XIL(0x555558492423)) at keyboard.c:956
#13 0x000055555570eb91 in internal_condition_case (bfun=bfun@entry=0x55555569f9c0 <command_loop_1>, handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x555555696310 <cmd_error>) at eval.c:1411
#14 0x00005555556907c4 in command_loop_2 (ignore=ignore@entry=XIL(0)) at lisp.h:1007
#15 0x000055555570eae9 in internal_catch (tag=tag@entry=XIL(0x5c70), func=func@entry=0x5555556907a0 <command_loop_2>, arg=arg@entry=XIL(0)) at eval.c:1176
#16 0x0000555555690719 in command_loop () at lisp.h:1007
#17 0x0000555555695f1a in recursive_edit_1 () at keyboard.c:720
#18 0x0000555555696256 in Frecursive_edit () at keyboard.c:789
#19 0x000055555570fa9b in Ffuncall (nargs=1, args=args@entry=0x7fffffffc700) at lisp.h:2081
#20 0x000055555574cb54 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
#21 0x000055555570f9d7 in Ffuncall (nargs=3, args=0x7fffffffcbb0) at eval.c:2893
#22 0x0000555555711b28 in Fapply (nargs=nargs@entry=2, args=args@entry=0x7fffffffcc50) at eval.c:2509
#23 0x00005555557101f5 in apply1 (arg=XIL(0x555557ee92a3), fn=<optimized out>) at lisp.h:1373
#24 call_debugger (arg=XIL(0x555557ee92a3)) at eval.c:339
#25 0x000055555571092d in maybe_call_debugger (data=XIL(0x555557ee92d3), sig=<optimized out>, conditions=XIL(0x7ffff1e724fb)) at lisp.h:1007
#26 signal_or_quit (error_symbol=<optimized out>, data=XIL(0x555557ee92d3), keyboard_quit=<optimized out>) at eval.c:1727
#27 0x00005555555a14c2 in Fsignal (error_symbol=<optimized out>, error_symbol@entry=XIL(0xf090), data=<optimized out>) at eval.c:1628
#28 0x00005555555a16a8 in xsignal (data=<optimized out>, error_symbol=XIL(0xf090)) at lisp.h:4115
#29 xsignal2 (error_symbol=error_symbol@entry=XIL(0xf090), arg1=arg1@entry=XIL(0xa7d0), arg2=<optimized out>) at eval.c:1787
#30 0x00005555555a070c in wrong_type_argument (predicate=predicate@entry=XIL(0xa7d0), value=<optimized out>) at lisp.h:1007
#31 0x00005555555a0726 in CHECK_TYPE (x=<optimized out>, predicate=XIL(0xa7d0), ok=0) at lisp.h:758
#32 check_number_coerce_marker (x=<optimized out>) at data.c:2377
#33 0x00005555556fd5cd in arithcompare (num1=make_fixnum(1), num2=XIL(0x8550), comparison=comparison@entry=ARITH_EQUAL) at data.c:2390
#34 0x000055555574ead4 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:990
#35 0x000055555570f9d7 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffffd218) at eval.c:2893
#36 0x000055555570c175 in Ffuncall_interactively (nargs=2, args=0x7fffffffd218) at callint.c:253
#37 0x000055555570fa9b in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7fffffffd210) at lisp.h:2081
#38 0x000055555570d68b in Fcall_interactively (function=<optimized out>, record_flag=<optimized out>, keys=<optimized out>) at callint.c:784
#39 0x000055555570fa9b in Ffuncall (nargs=4, args=args@entry=0x7fffffffd448) at lisp.h:2081
#40 0x000055555574cb54 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:632
#41 0x000055555570f9d7 in Ffuncall (nargs=5, args=0x7fffffffd7b0) at eval.c:2893
#42 0x000055555570fc9d in call4 (fn=fn@entry=XIL(0x43b0), arg1=arg1@entry=XIL(0x2aaa9c29dce0), arg2=arg2@entry=XIL(0), arg3=<optimized out>, arg4=arg4@entry=XIL(0x30)) at eval.c:2761
#43 0x000055555569c0a0 in read_char (commandflag=1, map=XIL(0x5555585fc1b3), prev_event=XIL(0), used_mouse_menu=0x7fffffffddfb, end_time=0x0) at lisp.h:1007
#44 0x000055555569e224 in read_key_sequence (keybuf=<optimized out>, prompt=XIL(0), dont_downcase_last=<optimized out>, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=<optimized out>) at keyboard.c:9483
#45 0x000055555569fbbc in command_loop_1 () at lisp.h:1007
#46 0x000055555570eba7 in internal_condition_case (bfun=bfun@entry=0x55555569f9c0 <command_loop_1>, handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x555555696310 <cmd_error>) at eval.c:1415
#47 0x00005555556907c4 in command_loop_2 (ignore=ignore@entry=XIL(0)) at lisp.h:1007
#48 0x000055555570eae9 in internal_catch (tag=tag@entry=XIL(0xd7d0), func=func@entry=0x5555556907a0 <command_loop_2>, arg=arg@entry=XIL(0)) at eval.c:1176
#49 0x0000555555690763 in command_loop () at lisp.h:1007
#50 0x0000555555695f1a in recursive_edit_1 () at keyboard.c:720
#51 0x0000555555696256 in Frecursive_edit () at keyboard.c:789
#52 0x00005555555a6a39 in main (argc=1, argv=<optimized out>) at emacs.c:2054

Lisp Backtrace:
"command-error-default-function" (0xffffc058)
"apply" (0xffffc168)
0xf22de0f8 PVEC_COMPILED
"recursive-edit" (0xffffc708)
"debug" (0xffffcbb8)
"dbus-handle-event" (0xffffd220)
"funcall-interactively" (0xffffd218)
"call-interactively" (0xffffd450)
"command-execute" (0xffffd7b8)

These crashes occur only in optimized builds.
I tried to print DBUS events in dbus-handle-event
to stdout, so in case of the crash, at least stdout
might show the cause of the problem, but can't find
a Lisp function that prints to stdout.  I tried
to add in dbus-handle-event:

  (let ((noninteractive t)) (message "DBUS: %S" event))

but it doesn't print to stdout.

bug#45277: D-Bus crashes and DND errors

[Michael Albinus]

Juri Linkov <juri@linkov.net> writes:

Hi Juri,

> These crashes occur only in optimized builds.
> I tried to print DBUS events in dbus-handle-event
> to stdout, so in case of the crash, at least stdout
> might show the cause of the problem, but can't find
> a Lisp function that prints to stdout.  I tried
> to add in dbus-handle-event:
>
>   (let ((noninteractive t)) (message "DBUS: %S" event))
>
> but it doesn't print to stdout.

dbusbind.c is prepared to write traces. Pls recompile dbusbind.o with
"make MYCPPFLAGS='-DDBUS_DEBUG'", as indicated in that file (line 98).

Best regards, Michael.

bug#45277: D-Bus crashes and DND errors

[Juri Linkov]

> dbusbind.c is prepared to write traces. Pls recompile dbusbind.o with
> "make MYCPPFLAGS='-DDBUS_DEBUG'", as indicated in that file (line 98).

Thanks for the hint, I'll recompile dbusbind.c and see what happens next time.

Meanwhile, here is today's error (not crash):

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

bug#45277: D-Bus crashes and DND errors

[Michael Albinus]

Juri Linkov <juri@linkov.net> writes:

Hi Juri,

> Meanwhile, here is today's error (not crash):
>
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>   dbus-handle-event((dbus-event (- arg)))
>   funcall-interactively(dbus-handle-event (dbus-event (- arg)))
>   call-interactively(dbus-handle-event nil [(dbus-event (- arg))])
>   command-execute(dbus-handle-event nil [(dbus-event (- arg))] t)

I'm completely lost. Where does this interactive call of
dbus-handle-event comes from? And where those strange arguments? Well,
there's a wannabe D-Bus event "(dbus-event (- arg))", but I have no
idea how it is composed.

Do you have a recipe how to provoke this error? Or could you bisect
Emacs git in order to find the change which has introduced the problem?

Best regards, Michael.

bug#45277: D-Bus crashes and DND errors

[Juri Linkov]

>> Meanwhile, here is today's error (not crash):
>>
>> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>>   dbus-handle-event((dbus-event (- arg)))
>>   funcall-interactively(dbus-handle-event (dbus-event (- arg)))
>>   call-interactively(dbus-handle-event nil [(dbus-event (- arg))])
>>   command-execute(dbus-handle-event nil [(dbus-event (- arg))] t)
>
> I'm completely lost. Where does this interactive call of
> dbus-handle-event comes from? And where those strange arguments? Well,
> there's a wannabe D-Bus event "(dbus-event (- arg))", but I have no
> idea how it is composed.

I don't know, it seems xd_retrieve_arg tries to decode received data,
but when it receives garbage, then "Garbage In - Garbage Out".

> Do you have a recipe how to provoke this error? Or could you bisect
> Emacs git in order to find the change which has introduced the problem?

These errors appear at the rate of one error per day,
so no bisecting is possible in a reasonable time.
Today dbus-handle-event signaled the error with
a string of 6 random bytes, and not crashed, but
I forgot to look at traces, so no luck this time.

bug#45277: D-Bus crashes and DND errors

[Juri Linkov]

> Do you have a recipe how to provoke this error?

After dbus-handle-event started to pull random parts of the init file
to use as its event arg, I realized that something is wrong with the build,
made clean bootstrap, and D-Bus problems went away.  Sorry for false alarm.

The second part of this bug report was about DND errors, that
is unrelated to D-Bus, but DND errors should be fixed anyway.

Here's a test case for DND errors:

Eval:
(modify-frame-parameters nil '((undecorated . t)))
(toggle-frame-maximized)

(frame-parameter nil 'left)
=> (+ -1)

Since it's not a number, x-dnd-handle-xdnd signals the error:

  Bad data in VALUES, must be number, cons or string

bug#45277: D-Bus crashes and DND errors

[Michael Albinus]

Juri Linkov <juri@linkov.net> writes:

Hi Juri,

>> Do you have a recipe how to provoke this error?
>
> After dbus-handle-event started to pull random parts of the init file
> to use as its event arg, I realized that something is wrong with the build,
> made clean bootstrap, and D-Bus problems went away.  Sorry for false alarm.

No problem, I'm happy there's no random bug in dbusbind.c.

Best regards, Michael.

bug#45277: D-Bus crashes and DND errors

[Juri Linkov]

retitle 45277 Non-DBus crashes
quit

>>> Do you have a recipe how to provoke this error?
>>
>> After dbus-handle-event started to pull random parts of the init file
>> to use as its event arg, I realized that something is wrong with the build,
>> made clean bootstrap, and D-Bus problems went away.  Sorry for false alarm.
>
> No problem, I'm happy there's no random bug in dbusbind.c.

Bad news: after pull from master and recompiling it crashes again.

Good news: crashes are not caused by dbusbind.c.

Usually, DBUS_DEBUG prints such lines:

  xd_read_message_1: Event received: ...
  xd_read_message_1: Event stored: ...
  xd_read_message_1: Event received: ...
  xd_read_message_1: Event stored: ...
  ...

But when such error is signaled:

  Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p "Click to close tab")
    dbus-handle-event((dbus-event :help "Click to close tab"))
    funcall-interactively(dbus-handle-event (dbus-event :help "Click to close tab"))
    call-interactively(dbus-handle-event nil [(dbus-event :help "Click to close tab")])
    command-execute(dbus-handle-event nil [(dbus-event :help "Click to close tab")] t)

there were no DBUS_DEBUG messages before this error comes.
So the erroneous events are not added by dbusbind.c.

Here's is a brief sequence of events:

1. In web browser copied a URL to the clipboard;
2. In Emacs this immediately causes a DBUS_EVENT event added to kbd_buffer:

Thread 1 "emacs" hit Breakpoint 5, make_lispy_event (event=0x555555cb93c8 <kbd_buffer+100520>) at keyboard.c:6015
6015		return Fcons (Qdbus_event, event->arg);

(gdb) bt
#0  make_lispy_event (event=0x555555cb93c8 <kbd_buffer+100520>) at keyboard.c:6015
#1  0x00005555557131b9 in kbd_buffer_get_event (kbp=0x7fffffffc668, used_mouse_menu=0x7fffffffdcb9, end_time=0x0) at keyboard.c:3978
#2  0x000055555570ed06 in read_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffcab0, used_mouse_menu=0x7fffffffdcb9) at keyboard.c:2159
#3  0x000055555570f023 in read_decoded_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffcab0, prev_event=XIL(0), used_mouse_menu=0x7fffffffdcb9) at keyboard.c:2223
#4  0x0000555555710857 in read_char (commandflag=1, map=XIL(0x55555a5c9943), prev_event=XIL(0), used_mouse_menu=0x7fffffffdcb9, end_time=0x0) at keyboard.c:2833
#5  0x000055555571fab7 in read_key_sequence (keybuf=0x7fffffffdee0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9498
#6  0x000055555570c918 in command_loop_1 () at keyboard.c:1353
#7  0x00005555557caed4 in internal_condition_case (bfun=0x55555570c4b0 <command_loop_1>, handlers=XIL(0x90), hfun=0x55555570bbed <cmd_error>) at eval.c:1415
#8  0x000055555570c154 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1094
#9  0x00005555557ca6d7 in internal_catch (tag=XIL(0xd800), func=0x55555570c123 <command_loop_2>, arg=XIL(0)) at eval.c:1176
#10 0x000055555570c0ef in command_loop () at keyboard.c:1073
#11 0x000055555570b79e in recursive_edit_1 () at keyboard.c:720
#12 0x000055555570b929 in Frecursive_edit () at keyboard.c:789
#13 0x00005555557080a0 in main (argc=1, argv=0x7fffffffe368) at emacs.c:2054

(gdb) fr 1
#1  0x00005555557131b9 in kbd_buffer_get_event (kbp=0x7fffffffc668, used_mouse_menu=0x7fffffffdcb9, end_time=0x0) at keyboard.c:3978
3978	          obj = make_lispy_event (&event->ie);

(gdb) p event->kind
$1 = DBUS_EVENT

(gdb) p (int)event->kind
$2 = 27

(gdb) p event->ie
$3 = {
  kind = DBUS_EVENT,
  part = scroll_bar_nowhere,
  code = 0,
  modifiers = 0,
  x = XIL(0),
  y = XIL(0),
  timestamp = 0,
  frame_or_window = XIL(0),
  arg = XIL(0x555557db7e23)
}

(gdb) p event->ie->arg
$4 = XIL(0x555557db7e23)

(gdb) pr
(:help "Click to close tab")

(gdb) p event->sie
$5 = {
  kind = DBUS_EVENT,
  dpyinfo = 0x0,
  requestor = 0,
  selection = 0,
  target = 0,
  property = 0,
  time = 0
}

(gdb) c
Continuing.

Thread 1 "emacs" hit Breakpoint 5, make_lispy_event (event=0x555555cbd0d0 <kbd_buffer+116144>) at keyboard.c:6015
6015		return Fcons (Qdbus_event, event->arg);

(gdb) fr 1
#1  0x00005555557131b9 in kbd_buffer_get_event (kbp=0x7fffffffc668, used_mouse_menu=0x7fffffffdcb9, end_time=0x0) at keyboard.c:3978
3978	          obj = make_lispy_event (&event->ie);

(gdb) p event->kind
$6 = DBUS_EVENT

(gdb) p event->ie
$7 = {
  kind = DBUS_EVENT,
  part = scroll_bar_nowhere,
  code = 0,
  modifiers = 0,
  x = XIL(0),
  y = XIL(0),
  timestamp = 0,
  frame_or_window = XIL(0),
  arg = XIL(0x555560a70f43)
}

(gdb) p event->ie->arg
$8 = XIL(0x555560a70f43)

(gdb) pr
#<INVALID_LISP_OBJECT 0x555560a70f43>

(gdb) c
Continuing.

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
string_intervals (s=XIL(0x6c613a5b5e5b285c)) at lisp.h:3404
3404	  return XSTRING (s)->u.s.intervals;

Maybe making bootstrap after every pull from master will solve these problems?

bug#45277: D-Bus crashes and DND errors

[Michael Albinus]

Juri Linkov <juri@linkov.net> writes:

Hi Juri,

> But when such error is signaled:
>
>   Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p "Click to close tab")
>     dbus-handle-event((dbus-event :help "Click to close tab"))
>     funcall-interactively(dbus-handle-event (dbus-event :help "Click to close tab"))
>     call-interactively(dbus-handle-event nil [(dbus-event :help "Click to close tab")])
>     command-execute(dbus-handle-event nil [(dbus-event :help "Click to close tab")] t)
>
> there were no DBUS_DEBUG messages before this error comes.
> So the erroneous events are not added by dbusbind.c.

Good.

> Here's is a brief sequence of events:
>
> 1. In web browser copied a URL to the clipboard;
> 2. In Emacs this immediately causes a DBUS_EVENT event added to kbd_buffer:
>
> Thread 1 "emacs" hit Breakpoint 5, make_lispy_event (event=0x555555cb93c8 <kbd_buffer+100520>) at keyboard.c:6015
> 6015		return Fcons (Qdbus_event, event->arg);
>
> (gdb) bt
> #0  make_lispy_event (event=0x555555cb93c8 <kbd_buffer+100520>) at keyboard.c:6015
> #1  0x00005555557131b9 in kbd_buffer_get_event (kbp=0x7fffffffc668, used_mouse_menu=0x7fffffffdcb9, end_time=0x0) at keyboard.c:3978
> #2  0x000055555570ed06 in read_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffcab0, used_mouse_menu=0x7fffffffdcb9) at keyboard.c:2159
> #3  0x000055555570f023 in read_decoded_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffffcab0, prev_event=XIL(0), used_mouse_menu=0x7fffffffdcb9) at keyboard.c:2223
> #4  0x0000555555710857 in read_char (commandflag=1, map=XIL(0x55555a5c9943), prev_event=XIL(0), used_mouse_menu=0x7fffffffdcb9, end_time=0x0) at keyboard.c:2833
> #5  0x000055555571fab7 in read_key_sequence (keybuf=0x7fffffffdee0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9498
> #6  0x000055555570c918 in command_loop_1 () at keyboard.c:1353
> #7  0x00005555557caed4 in internal_condition_case (bfun=0x55555570c4b0 <command_loop_1>, handlers=XIL(0x90), hfun=0x55555570bbed <cmd_error>) at eval.c:1415
> #8  0x000055555570c154 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1094
> #9  0x00005555557ca6d7 in internal_catch (tag=XIL(0xd800), func=0x55555570c123 <command_loop_2>, arg=XIL(0)) at eval.c:1176
> #10 0x000055555570c0ef in command_loop () at keyboard.c:1073
> #11 0x000055555570b79e in recursive_edit_1 () at keyboard.c:720
> #12 0x000055555570b929 in Frecursive_edit () at keyboard.c:789
> #13 0x00005555557080a0 in main (argc=1, argv=0x7fffffffe368) at emacs.c:2054
>
> (gdb) fr 1
> #1  0x00005555557131b9 in kbd_buffer_get_event (kbp=0x7fffffffc668, used_mouse_menu=0x7fffffffdcb9, end_time=0x0) at keyboard.c:3978
> 3978	          obj = make_lispy_event (&event->ie);
>
> (gdb) p event->kind
> $1 = DBUS_EVENT
>
> (gdb) p (int)event->kind
> $2 = 27
>
> (gdb) p event->ie
> $3 = {
>   kind = DBUS_EVENT,
>   part = scroll_bar_nowhere,
>   code = 0,
>   modifiers = 0,
>   x = XIL(0),
>   y = XIL(0),
>   timestamp = 0,
>   frame_or_window = XIL(0),
>   arg = XIL(0x555557db7e23)
> }
>
> (gdb) p event->ie->arg
> $4 = XIL(0x555557db7e23)
>
> (gdb) pr
> (:help "Click to close tab")
>
> (gdb) p event->sie
> $5 = {
>   kind = DBUS_EVENT,
>   dpyinfo = 0x0,
>   requestor = 0,
>   selection = 0,
>   target = 0,
>   property = 0,
>   time = 0
> }
>
> (gdb) c
> Continuing.
>
> Thread 1 "emacs" hit Breakpoint 5, make_lispy_event (event=0x555555cbd0d0 <kbd_buffer+116144>) at keyboard.c:6015
> 6015		return Fcons (Qdbus_event, event->arg);
>
> (gdb) fr 1
> #1  0x00005555557131b9 in kbd_buffer_get_event (kbp=0x7fffffffc668, used_mouse_menu=0x7fffffffdcb9, end_time=0x0) at keyboard.c:3978
> 3978	          obj = make_lispy_event (&event->ie);
>
> (gdb) p event->kind
> $6 = DBUS_EVENT
>
> (gdb) p event->ie
> $7 = {
>   kind = DBUS_EVENT,
>   part = scroll_bar_nowhere,
>   code = 0,
>   modifiers = 0,
>   x = XIL(0),
>   y = XIL(0),
>   timestamp = 0,
>   frame_or_window = XIL(0),
>   arg = XIL(0x555560a70f43)
> }
>
> (gdb) p event->ie->arg
> $8 = XIL(0x555560a70f43)
>
> (gdb) pr
> #<INVALID_LISP_OBJECT 0x555560a70f43>
>
> (gdb) c
> Continuing.
>
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> string_intervals (s=XIL(0x6c613a5b5e5b285c)) at lisp.h:3404
> 3404	  return XSTRING (s)->u.s.intervals;
>
> Maybe making bootstrap after every pull from master will solve these problems?

That would be too drastic. I have the impression, that the enum
event_kind (termhooks.h) is not in sync with its usage here and
there. When this file is changed, all *.c files (or at least all *.c
files using this) shall be recompiled.

In your local git checkout, what are the timestamps of termhooks.h,
dbusbind.c and dbusbind.o?

Best regards, Michael.

bug#45277: D-Bus crashes and DND errors

[Juri Linkov]

>> Maybe making bootstrap after every pull from master will solve these problems?
>
> That would be too drastic. I have the impression, that the enum
> event_kind (termhooks.h) is not in sync with its usage here and
> there. When this file is changed, all *.c files (or at least all *.c
> files using this) shall be recompiled.

This is what I suspected too, but I see nothing wrong.

> In your local git checkout, what are the timestamps of termhooks.h,
> dbusbind.c and dbusbind.o?

The timestamp of termhooks.h is the same as when BUFFER_SWITCH_EVENT
was removed 2020-12-12.  But the timestamp of dbusbind.c and dbusbind.o
is the same 2020-12-28.  All .o files are also 2020-12-28.

bug#45277: D-Bus crashes and DND errors

[Michael Albinus]

Juri Linkov <juri@linkov.net> writes:

Hi Juri,

>> In your local git checkout, what are the timestamps of termhooks.h,
>> dbusbind.c and dbusbind.o?
>
> The timestamp of termhooks.h is the same as when BUFFER_SWITCH_EVENT
> was removed 2020-12-12.  But the timestamp of dbusbind.c and dbusbind.o
> is the same 2020-12-28.  All .o files are also 2020-12-28.

Strange. Is there something special with the timestamp of globals.h?
Or do you have some special setup, like out-of-tree compilation?

(I'm just poking in the fog, I have no real idea)

Best regards, Michael.

bug#45277: D-Bus crashes and DND errors

[Juri Linkov]

>>> In your local git checkout, what are the timestamps of termhooks.h,
>>> dbusbind.c and dbusbind.o?
>>
>> The timestamp of termhooks.h is the same as when BUFFER_SWITCH_EVENT
>> was removed 2020-12-12.  But the timestamp of dbusbind.c and dbusbind.o
>> is the same 2020-12-28.  All .o files are also 2020-12-28.
>
> Strange. Is there something special with the timestamp of globals.h?
> Or do you have some special setup, like out-of-tree compilation?

Nothing special.  globals.h is 2020-12-28 too, and no out-of-tree compilation.
Before making bootstrap (that I believe should fix this problem again),
I could try more debugging.

bug#45277: D-Bus crashes and DND errors

[Michael Albinus]

Juri Linkov <juri@linkov.net> writes:

> Nothing special.  globals.h is 2020-12-28 too, and no out-of-tree compilation.
> Before making bootstrap (that I believe should fix this problem again),
> I could try more debugging.

Yes. But I have no idea what. Since it doesn't seem to be D-Bus
specific, I'd like if somebody else could join.

Best regards, Michael.

bug#45277: D-Bus crashes and DND errors

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Tue, 29 Dec 2020 11:59:10 +0100
> Cc: 45277@debbugs.gnu.org
> 
> Juri Linkov <juri@linkov.net> writes:
> 
> > Nothing special.  globals.h is 2020-12-28 too, and no out-of-tree compilation.
> > Before making bootstrap (that I believe should fix this problem again),
> > I could try more debugging.
> 
> Yes. But I have no idea what. Since it doesn't seem to be D-Bus
> specific, I'd like if somebody else could join.

I'm happy to help if I can, but I don't think I follow your line of
investigation (perhaps because I don't know enough about Dbus).  What
made you think that this could be caused by outdated files in the
working tree, and how does "make bootstrap" enter this picture?
Please be sure to describe the evidence you collected that led you to
those conclusions.

Armed with this information, I will try to come up with some ideas.

bug#45277: D-Bus crashes and DND errors

[Juri Linkov]

>> > Nothing special.  globals.h is 2020-12-28 too, and no out-of-tree compilation.
>> > Before making bootstrap (that I believe should fix this problem again),
>> > I could try more debugging.
>>
>> Yes. But I have no idea what. Since it doesn't seem to be D-Bus
>> specific, I'd like if somebody else could join.
>
> I'm happy to help if I can, but I don't think I follow your line of
> investigation (perhaps because I don't know enough about Dbus).  What
> made you think that this could be caused by outdated files in the
> working tree, and how does "make bootstrap" enter this picture?
> Please be sure to describe the evidence you collected that led you to
> those conclusions.
>
> Armed with this information, I will try to come up with some ideas.

Thanks for the help offer.  I see no more crashes even
without making bootstrap, so can't find an explanation.

bug#45277: D-Bus crashes and DND errors

[Michael Albinus]

Juri Linkov <juri@linkov.net> writes:

Hi Juri,

> Thanks for the help offer.  I see no more crashes even
> without making bootstrap, so can't find an explanation.

I've just pushed a change to dbusbind.c because of another
error. Although I don't see a coincidence with your problem, it might be
worth to pull and compile Emacs (no bootstrap).

Best regards, Michael.

bug#45277: SELECTION_CLEAR_EVENT crashes

[Juri Linkov]

retitle 45277 SELECTION_CLEAR_EVENT crashes
quit

>> Thanks for the help offer.  I see no more crashes even
>> without making bootstrap, so can't find an explanation.
>
> I've just pushed a change to dbusbind.c because of another
> error. Although I don't see a coincidence with your problem, it might be
> worth to pull and compile Emacs (no bootstrap).

After a week of calm, the crashes returned, but now with
a breakpoint in kbd_buffer_store_buffered_event, it revealed
that after copying a text to the clipboard outside of Emacs
causes the broken event SELECTION_CLEAR_EVENT to be added to the
kbd queue.  Sometimes the event kind becomes 11, sometimes 27.
Their binary representations:

#b01011 => 11 (SELECTION_CLEAR_EVENT)
#b11011 => 27 (DBUS_EVENT)
   ====
Note that their suffixes are the same "1011",
and only the leading bit differs.

Looks like a bit flip that means a faulty memory.
Maybe I should acquire ECC memory as Linus suggested
https://www.realworldtech.com/forum/?threadid=198497&curpostid=198647

bug#45277: SELECTION_CLEAR_EVENT crashes

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> #b01011 => 11 (SELECTION_CLEAR_EVENT)
> #b11011 => 27 (DBUS_EVENT)
>    ====
> Note that their suffixes are the same "1011",
> and only the leading bit differs.
>
> Looks like a bit flip that means a faulty memory.
> Maybe I should acquire ECC memory as Linus suggested

If this is a hardware error, then perhaps this bug report can be closed?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45277: SELECTION_CLEAR_EVENT crashes

[Juri Linkov]

>> #b01011 => 11 (SELECTION_CLEAR_EVENT)
>> #b11011 => 27 (DBUS_EVENT)
>>    ====
>> Note that their suffixes are the same "1011",
>> and only the leading bit differs.
>>
>> Looks like a bit flip that means a faulty memory.
>> Maybe I should acquire ECC memory as Linus suggested
>
> If this is a hardware error, then perhaps this bug report can be closed?

I have exactly the same crashes on completely different computers.
What surprises me is that no one else has these crashes.

bug#45277: SELECTION_CLEAR_EVENT crashes

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> I have exactly the same crashes on completely different computers.
> What surprises me is that no one else has these crashes.

OK, then it can hardly be a hardware issue.  I can't recall seeing any
other bug reports (from others) in this area, though, so it does seem
like nobody else experiences these problems.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45277: SELECTION_CLEAR_EVENT crashes

[Juri Linkov]

>> I have exactly the same crashes on completely different computers.
>> What surprises me is that no one else has these crashes.
>
> OK, then it can hardly be a hardware issue.  I can't recall seeing any
> other bug reports (from others) in this area, though, so it does seem
> like nobody else experiences these problems.

It seems these crashes are GC-related.  They started to appear after Sep 2020.
And after recent GC-related changes there are no more crashes, but after
every screen lock/unlock, a produced DBUS event causes random errors.
Here are some examples:

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p ("\\.makepp\\'" . makefile-makepp-mode))
  dbus-handle-event((dbus-event ("Makeppfile\\(?:\\.mk\\)?\\'" . makefile-makepp-mode) ...))
  funcall-interactively(dbus-handle-event (dbus-event ("Makeppfile\\(?:\\.mk\\)?\\'" . makefile-makepp-mode) ...))
  call-interactively(dbus-handle-event nil [(dbus-event ("Makeppfile\\(?:\\.mk\\)?\\'" . makefile-makepp-mode) ...)])
  command-execute(dbus-handle-event nil [(dbus-event ("Makeppfile\\(?:\\.mk\\)?\\'" . makefile-makepp-mode) ...)] t)

Debugger entered--Lisp error: (wrong-type-argument listp "Monospace 10")
  dbus-check-event((dbus-event :user-spec . "Monospace 10"))
  dbus-handle-event((dbus-event :user-spec . "Monospace 10"))
  funcall-interactively(dbus-handle-event (dbus-event :user-spec . "Monospace 10"))
  call-interactively(dbus-handle-event nil [(dbus-event :user-spec . "Monospace 10")])
  command-execute(dbus-handle-event nil [(dbus-event :user-spec . "Monospace 10")] t)

Debugger entered--Lisp error: (wrong-type-argument listp "#ffffffffffff")
  dbus-handle-event((dbus-event background-color . "#ffffffffffff"))
  funcall-interactively(dbus-handle-event (dbus-event background-color . "#ffffffffffff"))
  call-interactively(dbus-handle-event nil [(dbus-event background-color . "#ffffffffffff")])
  command-execute(dbus-handle-event nil [(dbus-event background-color . "#ffffffffffff")] t)

The last error contains part of (frame-parameter nil 'background-color) => "#ffffffffffff"

And after doing 'M-x garbage-collect' there are no more errors on screen lock/unlock.

Maybe GC-related changes didn't cause these errors, but just changed the behavior
of some memory leak in DBUS-related code?

bug#45277: SELECTION_CLEAR_EVENT crashes

[Juri Linkov]

> Maybe GC-related changes didn't cause these errors, but just changed the behavior
> of some memory leak in DBUS-related code?

Here is another error, maybe because I edited isearch.el:

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p (isearch-case-fold-search t isearch-regexp-function char-fold-to-regexp))
  dbus-handle-event((dbus-event 7 (isearch-case-fold-search t isearch-regexp-function char-fold-to-regexp)))
  funcall-interactively(dbus-handle-event (dbus-event 7 (isearch-case-fold-search t isearch-regexp-function char-fold-to-regexp)))
  call-interactively(dbus-handle-event nil [(dbus-event 7 (isearch-case-fold-search t isearch-regexp-function char-fold-to-regexp))])
  command-execute(dbus-handle-event nil [(dbus-event 7 (isearch-case-fold-search t isearch-regexp-function char-fold-to-regexp))] t)

bug#45277: SELECTION_CLEAR_EVENT crashes

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>>> I have exactly the same crashes on completely different computers.
>>> What surprises me is that no one else has these crashes.
>>
>> OK, then it can hardly be a hardware issue.  I can't recall seeing any
>> other bug reports (from others) in this area, though, so it does seem
>> like nobody else experiences these problems.
>
> It seems these crashes are GC-related.  They started to appear after Sep 2020.
> And after recent GC-related changes there are no more crashes, but after
> every screen lock/unlock, a produced DBUS event causes random errors.
> Here are some examples:

[...]

> Debugger entered--Lisp error: (wrong-type-argument listp "#ffffffffffff")
>   dbus-handle-event((dbus-event background-color . "#ffffffffffff"))
>   funcall-interactively(dbus-handle-event (dbus-event background-color
> . "#ffffffffffff"))
>   call-interactively(dbus-handle-event nil [(dbus-event
> background-color . "#ffffffffffff")])
>   command-execute(dbus-handle-event nil [(dbus-event background-color
> . "#ffffffffffff")] t)
>
> The last error contains part of (frame-parameter nil
> 'background-color) => "#ffffffffffff"
>
> And after doing 'M-x garbage-collect' there are no more errors on
> screen lock/unlock.
>
> Maybe GC-related changes didn't cause these errors, but just changed
> the behavior of some memory leak in DBUS-related code?

Hm, might be.  I've added Paul to the CCs -- perhaps he has some input
here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45277: DND errors

[Juri Linkov]

retitle 45277 DND errors
tags 45277 patch
quit

> Here's a test case for DND errors:
>
> Eval:
> (modify-frame-parameters nil '((undecorated . t)))
> (toggle-frame-maximized)
>
> (frame-parameter nil 'left)
> => (+ -1)
>
> Since it's not a number, x-dnd-handle-xdnd signals the error:
>
>   Bad data in VALUES, must be number, cons or string

I found that semantic-displayer-point-position checks for such syntax
and copied the same code to x-dnd-get-drop-x-y:

diff --git a/lisp/x-dnd.el b/lisp/x-dnd.el
index 1d49f46253..5af5490360 100644
--- a/lisp/x-dnd.el
+++ b/lisp/x-dnd.el
@@ -411,8 +411,10 @@ x-dnd-get-drop-x-y
 FRAME is the frame and W is the window where the drop happened.
 If W is a window, return its absolute coordinates,
 otherwise return the frame coordinates."
-  (let* ((frame-left (frame-parameter frame 'left))
-	 (frame-top (frame-parameter frame 'top)))
+  (let* ((frame-left (or (car-safe (cdr-safe (frame-parameter frame 'left)))
+			 (frame-parameter frame 'left)))
+	 (frame-top (or (car-safe (cdr-safe (frame-parameter frame 'top)))
+			(frame-parameter frame 'top))))
     (if (windowp w)
 	(let ((edges (window-inside-pixel-edges w)))
 	  (cons