bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#21313: 25.0.50; Strange errors from dbus-handle-event
Date: Sat, 03 Oct 2015 00:10:36 +0300

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: rpluim@gmail.com,  21313@debbugs.gnu.org
> Date: Fri, 02 Oct 2015 22:33:08 +0200
> 
> > 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.

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.

> > 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.

> 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.

Yes.

> 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?

Btw, dbusbind.c seems to have its own debugging facilities, so another
idea would be to turn them on.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]