Subject: bug#21313: 25.0.50; Strange errors from dbus-handle-event

From: Eli Zaretskii <[email-masked]>
Date: Sat, 03 Oct 2015 12:53:18 +0300

> From: Tassilo Horn <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked]
> Date: Sat, 03 Oct 2015 10:10:58 +0200
> 
> In toplevel form:
> notifications.el:37:1:Error: Wrong type argument: number-or-marker-p, [(dbus-event :system 2 2 "org.freedesktop.DBus" nil nil nil dbus-call-method-handler) nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil]
> Makefile:269: recipe for target 'notifications.elc' failed
> make[2]: *** [notifications.elc] Error 1

You need to run this under GDB to see what's going on.

> I guess that naive approach won't work because make_lispy_event is not
> free of side-effects.  It actually modifies the event so calling it
> twice per event has negative consequences.

Indeed, you probably should construct the Lisp object from the event
by hand.  Especially since we suspect some events might be invalid.

> Well, I now try following Michaels suggesting of reverting this one
> commit about `unread-command-events'.

That's okay, but only as a means of switching your attention to the
alternative source of those bogus events (like unread-command-events).
The commit mentioned by Michael is not going to go away, as it fixes a
bad problem.  However, it might need some adjustments to prevent
adverse side effects, if indeed reverting it will solve these
problems.