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

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> apparently my commits

Next strangeness: in this very mail I wanted to kill all lines until the
one below but apparently the line above was skipped.  View lossage says
 ...
 C-k [kill-line]
 <down> [next-line]
 C-k [kill-line]
 ...
but I've never pressed <down>.

And another thing which occurs to me recently (which might be completely
unrelated) is that I visit a file, and the effect of any key I type
becomes visible only after the next key has been pressed.

>> Should I revert these two commits?
>
> I understand those commits made the situation better, perhaps even
> much better.  If that's correct, I see no reason to revert them,

I had that feeling initially but it might be completely subjective and
wrong.  Maybe I just didn't write email too often on these better days,
I don't know.  But the last few days were horrible again.

> just to continue investigating the problem.

Yes, of course.

> One idea for investigation would be to write special code that would
> collect data about these events, from the moment they are detected by
> pselect until they wind up in the D-bus handler, and put that data
> into a data structure accessible from Lisp.  Then you could examine
> that data when the problem happens, and analyze it.

Well, yes, but I have no idea how to do that.

As far as I understand, that loop that I've patched is the thing which
calls callbacks which read input from file descriptors in order to
create Dbus or file-notify events.  Looking at the last error

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p 
CHARACTER_POSITION)
  dbus-handle-event((dbus-event FILE_NAME CHARACTER_POSITION LINE_NUMBER 
COLUMN_NUMBER OWNER_OS HOST_NAME USER CLASS NAME ATOM INTEGER SAVE_TARGETS))
  funcall-interactively(dbus-handle-event (dbus-event FILE_NAME 
CHARACTER_POSITION LINE_NUMBER COLUMN_NUMBER OWNER_OS HOST_NAME USER CLASS NAME 
ATOM INTEGER SAVE_TARGETS))
  call-interactively(dbus-handle-event nil [(dbus-event FILE_NAME 
CHARACTER_POSITION LINE_NUMBER COLUMN_NUMBER OWNER_OS HOST_NAME USER CLASS NAME 
ATOM INTEGER SAVE_TARGETS)])
  command-execute(dbus-handle-event nil [(dbus-event FILE_NAME 
CHARACTER_POSITION LINE_NUMBER COLUMN_NUMBER OWNER_OS HOST_NAME USER CLASS NAME 
ATOM INTEGER SAVE_TARGETS)] t)

the thing passed to `dbus-handle-event' looks like a dbus event except
that its contents are bogus.  These events are created by
xd_read_message_1 in dbusbind.c, however that function is reasonable
strict and could not create the bogus event above, e.g., it calls
make_number on the event type which becomes the second item in a
dbus-event, i.e., the CHARACTER_POSITION above which is no number.

So what should that tell us?  I don't really know.

Bye,
Tassilo