From: Tassilo Horn <tsdh@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: rpluim@gmail.com, 21313@debbugs.gnu.org
Subject: bug#21313: 25.0.50; Strange errors from dbus-handle-event
Date: Fri, 02 Oct 2015 22:33:08 +0200 [thread overview]
Message-ID: <87twq9roxn.fsf@gnu.org> (raw)
In-Reply-To: <834mi95bx1.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 02 Oct 2015 22:05:14 +0300")
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
next prev parent reply other threads:[~2015-10-02 20:33 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-21 16:24 bug#21313: 25.0.50; Strange errors from dbus-handle-event Tassilo Horn
2015-09-09 20:43 ` Tassilo Horn
2015-09-11 12:28 ` Tassilo Horn
2015-09-11 12:39 ` Eli Zaretskii
2015-09-11 13:06 ` Tassilo Horn
2015-09-11 13:59 ` Eli Zaretskii
2015-09-15 15:37 ` Tassilo Horn
2015-09-15 16:01 ` Eli Zaretskii
2015-09-16 11:39 ` Tassilo Horn
2015-09-22 5:49 ` Tassilo Horn
2015-09-22 8:00 ` Robert Pluim
2015-09-22 8:21 ` Tassilo Horn
2015-10-02 18:36 ` Tassilo Horn
2015-10-02 19:05 ` Eli Zaretskii
2015-10-02 20:33 ` Tassilo Horn [this message]
2015-10-02 21:10 ` Eli Zaretskii
2015-10-02 21:26 ` Michael Albinus
2015-10-03 5:40 ` Tassilo Horn
2015-10-03 6:32 ` Tassilo Horn
2015-10-03 7:14 ` Eli Zaretskii
2015-10-03 8:10 ` Tassilo Horn
2015-10-03 9:53 ` Eli Zaretskii
2015-10-03 12:06 ` Tassilo Horn
2015-10-03 7:43 ` Michael Albinus
2015-10-03 8:13 ` Tassilo Horn
2015-10-03 9:38 ` Tassilo Horn
2015-10-03 10:53 ` Eli Zaretskii
2015-10-14 9:58 ` Tassilo Horn
2015-10-14 17:05 ` Eli Zaretskii
2015-10-14 19:37 ` Tassilo Horn
2015-10-14 19:43 ` Eli Zaretskii
2015-10-15 11:37 ` Tassilo Horn
2015-10-15 16:56 ` Eli Zaretskii
2015-10-15 17:35 ` Tassilo Horn
2015-10-15 19:44 ` Eli Zaretskii
2015-10-16 4:53 ` Tassilo Horn
2015-10-16 7:02 ` Eli Zaretskii
2015-10-16 7:45 ` Tassilo Horn
2015-10-16 8:23 ` Eli Zaretskii
2015-10-16 9:25 ` Tassilo Horn
2015-10-16 10:11 ` Eli Zaretskii
2015-10-16 10:22 ` Tassilo Horn
2015-10-29 7:43 ` Tassilo Horn
2015-10-29 16:19 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87twq9roxn.fsf@gnu.org \
--to=tsdh@gnu.org \
--cc=21313@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=rpluim@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.