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

[Tassilo Horn <tsdh@gnu.org>]

Michael Albinus <michael.albinus@gmx.de> writes:

> If you feel that the changes didn't improve the situation, then
> reverting them is indeed TRT, IMO.  At the very least, the code will
> be simpler after the revert.

Ok, done that now.

>>> 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?
>>
>> Either that the event was not a valid D-Bus event, or that it weasn't
>> created by that function?
>
> From the backtrace I have the feeling that it was created as another
> event, and the marker `dbus-event' has been pushed there later. But I
> cannot prove this.

I have the same feeling as Michael.  xd_read_message_1 and
inotify_callback / inotifyevent_to_event are the only functions creating
dbus and file-notify events here, and they'd all barf if the data they
read was screwed.

And keep in mind that it's not only about these kinds events.  Sometimes
keyboard events also get screwed, e.g., in the case where view-lossage
tells me that I've typed a key which I actually didn't.  Or in the case
where I get a crash where probably the event is handled on the C-level
where a broken event causes a segfault instead of being gracefully put
in the debugger.

> > > 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.
> 
> What are your difficulties?
> 
> Basically, the idea is to record the last N events in some Lisp data
> structure.  I would start with raw events as they are read from the
> various sources, and move higher up the "food chain" as you gather
> more insight into the problem.

My problem is that the search space is not so small.  Assuming that
events are created correctly at first, I'd probably start recording
events at kbd_buffer_store_event but then I'd want to track when, where,
and how they are modified.  Well, just the first would be better than
nothing I guess.  I'll try that out.

If I had at least a reproducible recipe, I'd just try reverting the
changes to keyboard.c of the last months one by one and see if I can
find the culprit.  But right now (with my invalid reverted in process.c
fixes) I'm unable to provoke such an error although I've tried very
hard.

>> Btw, dbusbind.c seems to have its own debugging facilities, so
>> another idea would be to turn them on.
>
> Yes. Compiling dbusbind.c with the setting MYCPPFLAGS=-DDBUS_DEBUG
> enables traces to emacs' STDOUT. Don't hesitate to ask if you need
> more information for interpretation of them.
>
> You can also add more traces in dbusbind.c using the macro
> XD_DEBUG_MESSAGE.

I'm using that now but as said, I don't think that's where the problem
is.

Bye,
Tassilo