* bug#21313: 25.0.50; Strange errors from dbus-handle-event
@ 2015-08-21 16:24 Tassilo Horn
2015-09-09 20:43 ` Tassilo Horn
0 siblings, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-08-21 16:24 UTC (permalink / raw)
To: 21313
Since some time, I have very strange problems in Gnus' message-mode.
That is, I want to follow up to some message and press `F' so that I get
a new message-mode buffer with the quoted text of the original message.
Then I want to kill the text which I don't comment on. I do that by
simply setting point above the text to be killed and press and hold C-k.
When I do so, I frequently get errors like the one below. I have
totally no clue at all what that should mean to me. I grepped all elisp
files I have here (emacs itself + all packages I use) for
`funcall-interactively' but the only occurrence is in
`repeat-complex-command' which I did not call. I just did `kill-line'
repeatedly. I could reproduce the exact error a few times when trying
to follow up to different messages. Now, that doesn't happen anymore
though it's still the same emacs instance.
The vectors below denote auto-generated AUCTeX functions (see
`LaTeX-math-initialize') but don't see how those end up in dbus
events... I don't think that has something to do with AUCTeX
specifically. I had similar issues previously where during repeated
killing in a message-mode buffer point would just jump to some different
location which see below.
--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p ["≱ \\ngeq" LaTeX-math-ngeq t])
dbus-handle-event((dbus-event ["≯ \\ngtr" LaTeX-math-ngtr t] ["≱ \\ngeq" LaTeX-math-ngeq t] ["\\ngeqslant" LaTeX-math-ngeqslant t] ["\\ngeqq" LaTeX-math-ngeqq t] ["⪈ \\gneq" LaTeX-math-gneq t] ["≩ \\gneqq" LaTeX-math-gneqq t] ["\\gvertneqq" LaTeX-math-gvertneqq t] ["⋧ \\gnsim" LaTeX-math-gnsim t] ["⪊ \\gnapprox" LaTeX-math-gnapprox t] ["⊁ \\nsucc" LaTeX-math-nsucc t] ["\\nsucceq" LaTeX-math-nsucceq t] ["⋩ \\succnsim" LaTeX-math-succnsim t] ["⪺ \\succnapprox" LaTeX-math-succnapprox t] ["≇ \\ncong" LaTeX-math-ncong t] ["∦ \\nshortparallel" LaTeX-math-nshortparallel t] ["∦ \\nparallel" LaTeX-math-nparallel t] ["⊭ \\nvDash" LaTeX-math-nvDash t] ["⊯ \\nVDash" LaTeX-math-nVDash t] ["⋫ \\ntriangleright" LaTeX-math-ntriangleright t] ["⋭ \\ntrianglerighteq" LaTeX-math-ntrianglerighteq t] ["⊉ \\nsupseteq" LaTeX-math-nsupseteq t] ["\\nsupseteqq" LaTeX-math-nsupseteqq t] ["⊋ \\supsetneq" LaTeX-math-supsetneq t] ["\\varsupsetneq" LaTeX-math-varsupsetneq t] ["⫌ \\supsetneqq" LaTeX-math-supsetneqq t] ["\\varsupsetneqq" LaTeX-math-varsupsetneqq t]))
funcall-interactively(dbus-handle-event (dbus-event ["≯ \\ngtr" LaTeX-math-ngtr t] ["≱ \\ngeq" LaTeX-math-ngeq t] ["\\ngeqslant" LaTeX-math-ngeqslant t] ["\\ngeqq" LaTeX-math-ngeqq t] ["⪈ \\gneq" LaTeX-math-gneq t] ["≩ \\gneqq" LaTeX-math-gneqq t] ["\\gvertneqq" LaTeX-math-gvertneqq t] ["⋧ \\gnsim" LaTeX-math-gnsim t] ["⪊ \\gnapprox" LaTeX-math-gnapprox t] ["⊁ \\nsucc" LaTeX-math-nsucc t] ["\\nsucceq" LaTeX-math-nsucceq t] ["⋩ \\succnsim" LaTeX-math-succnsim t] ["⪺ \\succnapprox" LaTeX-math-succnapprox t] ["≇ \\ncong" LaTeX-math-ncong t] ["∦ \\nshortparallel" LaTeX-math-nshortparallel t] ["∦ \\nparallel" LaTeX-math-nparallel t] ["⊭ \\nvDash" LaTeX-math-nvDash t] ["⊯ \\nVDash" LaTeX-math-nVDash t] ["⋫ \\ntriangleright" LaTeX-math-ntriangleright t] ["⋭ \\ntrianglerighteq" LaTeX-math-ntrianglerighteq t] ["⊉ \\nsupseteq" LaTeX-math-nsupseteq t] ["\\nsupseteqq" LaTeX-math-nsupseteqq t] ["⊋ \\supsetneq" LaTeX-math-supsetneq t] ["\\varsupsetneq" LaTeX-math-varsupsetneq t] ["⫌ \\supsetneqq" LaTeX-math-supsetneqq t] ["\\varsupsetneqq" LaTeX-math-varsupsetneqq t]))
call-interactively(dbus-handle-event nil [(dbus-event ["≯ \\ngtr" LaTeX-math-ngtr t] ["≱ \\ngeq" LaTeX-math-ngeq t] ["\\ngeqslant" LaTeX-math-ngeqslant t] ["\\ngeqq" LaTeX-math-ngeqq t] ["⪈ \\gneq" LaTeX-math-gneq t] ["≩ \\gneqq" LaTeX-math-gneqq t] ["\\gvertneqq" LaTeX-math-gvertneqq t] ["⋧ \\gnsim" LaTeX-math-gnsim t] ["⪊ \\gnapprox" LaTeX-math-gnapprox t] ["⊁ \\nsucc" LaTeX-math-nsucc t] ["\\nsucceq" LaTeX-math-nsucceq t] ["⋩ \\succnsim" LaTeX-math-succnsim t] ["⪺ \\succnapprox" LaTeX-math-succnapprox t] ["≇ \\ncong" LaTeX-math-ncong t] ["∦ \\nshortparallel" LaTeX-math-nshortparallel t] ["∦ \\nparallel" LaTeX-math-nparallel t] ["⊭ \\nvDash" LaTeX-math-nvDash t] ["⊯ \\nVDash" LaTeX-math-nVDash t] ["⋫ \\ntriangleright" LaTeX-math-ntriangleright t] ["⋭ \\ntrianglerighteq" LaTeX-math-ntrianglerighteq t] ["⊉ \\nsupseteq" LaTeX-math-nsupseteq t] ["\\nsupseteqq" LaTeX-math-nsupseteqq t] ["⊋ \\supsetneq" LaTeX-math-supsetneq t] ["\\varsupsetneq" LaTeX-math-varsupsetneq t] ["⫌ \\supsetneqq" LaTeX-math-supsetneqq t] ["\\varsupsetneqq" LaTeX-math-varsupsetneqq t])])
command-execute(dbus-handle-event nil [(dbus-event ["≯ \\ngtr" LaTeX-math-ngtr t] ["≱ \\ngeq" LaTeX-math-ngeq t] ["\\ngeqslant" LaTeX-math-ngeqslant t] ["\\ngeqq" LaTeX-math-ngeqq t] ["⪈ \\gneq" LaTeX-math-gneq t] ["≩ \\gneqq" LaTeX-math-gneqq t] ["\\gvertneqq" LaTeX-math-gvertneqq t] ["⋧ \\gnsim" LaTeX-math-gnsim t] ["⪊ \\gnapprox" LaTeX-math-gnapprox t] ["⊁ \\nsucc" LaTeX-math-nsucc t] ["\\nsucceq" LaTeX-math-nsucceq t] ["⋩ \\succnsim" LaTeX-math-succnsim t] ["⪺ \\succnapprox" LaTeX-math-succnapprox t] ["≇ \\ncong" LaTeX-math-ncong t] ["∦ \\nshortparallel" LaTeX-math-nshortparallel t] ["∦ \\nparallel" LaTeX-math-nparallel t] ["⊭ \\nvDash" LaTeX-math-nvDash t] ["⊯ \\nVDash" LaTeX-math-nVDash t] ["⋫ \\ntriangleright" LaTeX-math-ntriangleright t] ["⋭ \\ntrianglerighteq" LaTeX-math-ntrianglerighteq t] ["⊉ \\nsupseteq" LaTeX-math-nsupseteq t] ["\\nsupseteqq" LaTeX-math-nsupseteqq t] ["⊋ \\supsetneq" LaTeX-math-supsetneq t] ["\\varsupsetneq" LaTeX-math-varsupsetneq t] ["⫌ \\supsetneqq" LaTeX-math-supsetneqq t] ["\\varsupsetneqq" LaTeX-math-varsupsetneqq t])] t)
--8<---------------cut here---------------end--------------->8---
It really seems that during repeated killing in message-mode, strange
things happen. Now I performed another test: in a message-mode buffer I
typed START, <return>, and then pressed and held C-k until it beeped,
and then did M-x view-lossage. That's the output:
--8<---------------cut here---------------start------------->8---
S [self-insert-command]
T [self-insert-command]
A [self-insert-command]
R [self-insert-command]
T [self-insert-command]
<return> [newline]
C-k [kill-line]
...
C-k [kill-line]
<up> [previous-line]
<up> [previous-line]
<up> [previous-line]
C-k [kill-line]
...
C-k [kill-line]
M-x [counsel-M-x]
<return> [ivy-done]
--8<---------------cut here---------------end--------------->8---
I did NOT press <up> between all those C-k! I just pressed and held
C-k.
I tried once again in another message-mode buffer, and this time out of
sudden point jumped below the text I wanted to kill. `view-lossage'
claimed that I've pressed <down> and C-/ (which is `undo-tree-undo'
here) several times. No, I did NOT!
I've tried repeated killing in elisp, org-mode, and a fundamental-mode
buffer but couldn't reproduce the issue there.
Any idea how to debug that?
In GNU Emacs 25.0.50.15 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6)
of 2015-08-21 on thinkpad-t440p
Repository revision: ff2f35fc478d0047fef4ae3e0b09f43c37961bec
Windowing system distributor `The X.Org Foundation', version 11.0.11702000
System Description: Arch Linux
Configured using:
`configure 'CFLAGS=-g -ggdb3 -O1''
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11
Important settings:
value of $LC_MONETARY: de_DE.utf8
value of $LC_NUMERIC: de_DE.utf8
value of $LC_TIME: de_DE.utf8
value of $LANG: en_US.utf8
locale-coding-system: utf-8-unix
Major mode: Group
Minor modes in effect:
gnus-topic-mode: t
TeX-PDF-mode: t
TeX-source-correlate-mode: t
hl-line-mode: t
global-company-mode: t
global-aggressive-indent-mode: t
gnus-undo-mode: t
pdf-occur-global-minor-mode: t
recentf-mode: t
global-undo-tree-mode: t
global-subword-mode: t
subword-mode: t
save-place-mode: t
savehist-mode: t
show-paren-mode: t
ivy-mode: t
minibuffer-depth-indicate-mode: t
diff-auto-refine-mode: t
global-git-commit-mode: t
async-bytecomp-package-mode: t
shell-dirtrack-mode: t
desktop-save-mode: t
electric-pair-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Recent messages:
250 2.0.0 Ok: queued as C9D606800DE
221 2.0.0 Bye
20150821T174035.585> Opening nnml server on archive...
20150821T174035.586> Opening nnml server on archive...done
Mark set
Wrote /home/horn/.gnus.d/News/archive/sent-mails/1218
Mark set
20150821T174036.087> nnimap read 0k from mail.messagingengine.com
Sending...done
20150821T174039.814> Exiting summary buffer and applying spam rules
Load-path shadows:
~/Repos/el/auctex/lpath hides ~/Repos/el/gnus/lisp/lpath
~/Repos/el/highlight-symbol.el/highlight-symbol hides /home/horn/.emacs.d/elpa/highlight-symbol-20150816.628/highlight-symbol
~/Repos/el/gnus/lisp/md4 hides /home/horn/Repos/el/emacs/lisp/md4
~/Repos/el/gnus/lisp/color hides /home/horn/Repos/el/emacs/lisp/color
~/Repos/el/gnus/lisp/format-spec hides /home/horn/Repos/el/emacs/lisp/format-spec
~/Repos/el/gnus/lisp/password-cache hides /home/horn/Repos/el/emacs/lisp/password-cache
~/Repos/el/gnus/lisp/hex-util hides /home/horn/Repos/el/emacs/lisp/hex-util
~/Repos/el/gnus/lisp/dns-mode hides /home/horn/Repos/el/emacs/lisp/textmodes/dns-mode
~/Repos/el/gnus/lisp/dig hides /home/horn/Repos/el/emacs/lisp/net/dig
~/Repos/el/gnus/lisp/hmac-md5 hides /home/horn/Repos/el/emacs/lisp/net/hmac-md5
~/Repos/el/gnus/lisp/ntlm hides /home/horn/Repos/el/emacs/lisp/net/ntlm
~/Repos/el/gnus/lisp/hmac-def hides /home/horn/Repos/el/emacs/lisp/net/hmac-def
~/Repos/el/gnus/lisp/rfc2104 hides /home/horn/Repos/el/emacs/lisp/net/rfc2104
~/Repos/el/gnus/lisp/sasl-ntlm hides /home/horn/Repos/el/emacs/lisp/net/sasl-ntlm
~/Repos/el/gnus/lisp/sasl-cram hides /home/horn/Repos/el/emacs/lisp/net/sasl-cram
~/Repos/el/gnus/lisp/dns hides /home/horn/Repos/el/emacs/lisp/net/dns
~/Repos/el/gnus/lisp/sasl hides /home/horn/Repos/el/emacs/lisp/net/sasl
~/Repos/el/gnus/lisp/tls hides /home/horn/Repos/el/emacs/lisp/net/tls
~/Repos/el/gnus/lisp/sasl-scram-rfc hides /home/horn/Repos/el/emacs/lisp/net/sasl-scram-rfc
~/Repos/el/gnus/lisp/netrc hides /home/horn/Repos/el/emacs/lisp/net/netrc
~/Repos/el/gnus/lisp/sasl-digest hides /home/horn/Repos/el/emacs/lisp/net/sasl-digest
~/Repos/el/gnus/lisp/uudecode hides /home/horn/Repos/el/emacs/lisp/mail/uudecode
~/Repos/el/gnus/lisp/binhex hides /home/horn/Repos/el/emacs/lisp/mail/binhex
~/Repos/el/gnus/lisp/hashcash hides /home/horn/Repos/el/emacs/lisp/mail/hashcash
~/Repos/el/gnus/lisp/canlock hides /home/horn/Repos/el/emacs/lisp/gnus/canlock
~/Repos/el/gnus/lisp/nneething hides /home/horn/Repos/el/emacs/lisp/gnus/nneething
~/Repos/el/gnus/lisp/mm-encode hides /home/horn/Repos/el/emacs/lisp/gnus/mm-encode
~/Repos/el/gnus/lisp/mm-util hides /home/horn/Repos/el/emacs/lisp/gnus/mm-util
~/Repos/el/gnus/lisp/rfc2047 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2047
~/Repos/el/gnus/lisp/nnml hides /home/horn/Repos/el/emacs/lisp/gnus/nnml
~/Repos/el/gnus/lisp/gnus-cus hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cus
~/Repos/el/gnus/lisp/gnus-range hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-range
~/Repos/el/gnus/lisp/gnus-int hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-int
~/Repos/el/gnus/lisp/gnus-cloud hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cloud
~/Repos/el/gnus/lisp/spam-stat hides /home/horn/Repos/el/emacs/lisp/gnus/spam-stat
~/Repos/el/gnus/lisp/nnmh hides /home/horn/Repos/el/emacs/lisp/gnus/nnmh
~/Repos/el/gnus/lisp/gnus-mlspl hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-mlspl
~/Repos/el/gnus/lisp/deuglify hides /home/horn/Repos/el/emacs/lisp/gnus/deuglify
~/Repos/el/gnus/lisp/gnus-gravatar hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-gravatar
~/Repos/el/gnus/lisp/nngateway hides /home/horn/Repos/el/emacs/lisp/gnus/nngateway
~/Repos/el/gnus/lisp/ietf-drums hides /home/horn/Repos/el/emacs/lisp/gnus/ietf-drums
~/Repos/el/gnus/lisp/mail-parse hides /home/horn/Repos/el/emacs/lisp/gnus/mail-parse
~/Repos/el/gnus/lisp/gnus-salt hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-salt
~/Repos/el/gnus/lisp/nnimap hides /home/horn/Repos/el/emacs/lisp/gnus/nnimap
~/Repos/el/gnus/lisp/gnus-draft hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-draft
~/Repos/el/gnus/lisp/mail-source hides /home/horn/Repos/el/emacs/lisp/gnus/mail-source
~/Repos/el/gnus/lisp/messcompat hides /home/horn/Repos/el/emacs/lisp/gnus/messcompat
~/Repos/el/gnus/lisp/pop3 hides /home/horn/Repos/el/emacs/lisp/gnus/pop3
~/Repos/el/gnus/lisp/nnmaildir hides /home/horn/Repos/el/emacs/lisp/gnus/nnmaildir
~/Repos/el/gnus/lisp/nnheader hides /home/horn/Repos/el/emacs/lisp/gnus/nnheader
~/Repos/el/gnus/lisp/gnus-cite hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cite
~/Repos/el/gnus/lisp/nndiary hides /home/horn/Repos/el/emacs/lisp/gnus/nndiary
~/Repos/el/gnus/lisp/gnus-diary hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-diary
~/Repos/el/gnus/lisp/nnfolder hides /home/horn/Repos/el/emacs/lisp/gnus/nnfolder
~/Repos/el/gnus/lisp/gnus-art hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-art
~/Repos/el/gnus/lisp/gnus-demon hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-demon
~/Repos/el/gnus/lisp/mml-sec hides /home/horn/Repos/el/emacs/lisp/gnus/mml-sec
~/Repos/el/gnus/lisp/nnir hides /home/horn/Repos/el/emacs/lisp/gnus/nnir
~/Repos/el/gnus/lisp/mm-partial hides /home/horn/Repos/el/emacs/lisp/gnus/mm-partial
~/Repos/el/gnus/lisp/gnus-registry hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-registry
~/Repos/el/gnus/lisp/gnus-icalendar hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-icalendar
~/Repos/el/gnus/lisp/compface hides /home/horn/Repos/el/emacs/lisp/gnus/compface
~/Repos/el/gnus/lisp/gnus-fun hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-fun
~/Repos/el/gnus/lisp/gnus-start hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-start
~/Repos/el/gnus/lisp/smiley hides /home/horn/Repos/el/emacs/lisp/gnus/smiley
~/Repos/el/gnus/lisp/gnus-picon hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-picon
~/Repos/el/gnus/lisp/spam-report hides /home/horn/Repos/el/emacs/lisp/gnus/spam-report
~/Repos/el/gnus/lisp/nntp hides /home/horn/Repos/el/emacs/lisp/gnus/nntp
~/Repos/el/gnus/lisp/nnnil hides /home/horn/Repos/el/emacs/lisp/gnus/nnnil
~/Repos/el/gnus/lisp/nndir hides /home/horn/Repos/el/emacs/lisp/gnus/nndir
~/Repos/el/gnus/lisp/gnus-srvr hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-srvr
~/Repos/el/gnus/lisp/smime hides /home/horn/Repos/el/emacs/lisp/gnus/smime
~/Repos/el/gnus/lisp/nnvirtual hides /home/horn/Repos/el/emacs/lisp/gnus/nnvirtual
~/Repos/el/gnus/lisp/gnus-notifications hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-notifications
~/Repos/el/gnus/lisp/nnspool hides /home/horn/Repos/el/emacs/lisp/gnus/nnspool
~/Repos/el/gnus/lisp/gnus-group hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-group
~/Repos/el/gnus/lisp/gnus-bcklg hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-bcklg
~/Repos/el/gnus/lisp/gnus-util hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-util
~/Repos/el/gnus/lisp/gnus-sieve hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-sieve
~/Repos/el/gnus/lisp/nndraft hides /home/horn/Repos/el/emacs/lisp/gnus/nndraft
~/Repos/el/gnus/lisp/nnagent hides /home/horn/Repos/el/emacs/lisp/gnus/nnagent
~/Repos/el/gnus/lisp/gnus-spec hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-spec
~/Repos/el/gnus/lisp/gnus-bookmark hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-bookmark
~/Repos/el/gnus/lisp/mml1991 hides /home/horn/Repos/el/emacs/lisp/gnus/mml1991
~/Repos/el/gnus/lisp/rfc2231 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2231
~/Repos/el/gnus/lisp/yenc hides /home/horn/Repos/el/emacs/lisp/gnus/yenc
~/Repos/el/gnus/lisp/gnus-undo hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-undo
~/Repos/el/gnus/lisp/ecomplete hides /home/horn/Repos/el/emacs/lisp/gnus/ecomplete
~/Repos/el/gnus/lisp/legacy-gnus-agent hides /home/horn/Repos/el/emacs/lisp/gnus/legacy-gnus-agent
~/Repos/el/gnus/lisp/utf7 hides /home/horn/Repos/el/emacs/lisp/gnus/utf7
~/Repos/el/gnus/lisp/rtree hides /home/horn/Repos/el/emacs/lisp/gnus/rtree
~/Repos/el/gnus/lisp/gnus-uu hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-uu
~/Repos/el/gnus/lisp/gnus-ml hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-ml
~/Repos/el/gnus/lisp/sieve hides /home/horn/Repos/el/emacs/lisp/gnus/sieve
~/Repos/el/gnus/lisp/gnus hides /home/horn/Repos/el/emacs/lisp/gnus/gnus
~/Repos/el/gnus/lisp/mml hides /home/horn/Repos/el/emacs/lisp/gnus/mml
~/Repos/el/gnus/lisp/message hides /home/horn/Repos/el/emacs/lisp/gnus/message
~/Repos/el/gnus/lisp/mml-smime hides /home/horn/Repos/el/emacs/lisp/gnus/mml-smime
~/Repos/el/gnus/lisp/gnus-eform hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-eform
~/Repos/el/gnus/lisp/gnus-agent hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-agent
~/Repos/el/gnus/lisp/gnus-logic hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-logic
~/Repos/el/gnus/lisp/mm-extern hides /home/horn/Repos/el/emacs/lisp/gnus/mm-extern
~/Repos/el/gnus/lisp/nndoc hides /home/horn/Repos/el/emacs/lisp/gnus/nndoc
~/Repos/el/gnus/lisp/sieve-manage hides /home/horn/Repos/el/emacs/lisp/gnus/sieve-manage
~/Repos/el/gnus/lisp/mm-decode hides /home/horn/Repos/el/emacs/lisp/gnus/mm-decode
~/Repos/el/gnus/lisp/starttls hides /home/horn/Repos/el/emacs/lisp/gnus/starttls
~/Repos/el/gnus/lisp/gnus-dired hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-dired
~/Repos/el/gnus/lisp/nnbabyl hides /home/horn/Repos/el/emacs/lisp/gnus/nnbabyl
~/Repos/el/gnus/lisp/nnmbox hides /home/horn/Repos/el/emacs/lisp/gnus/nnmbox
~/Repos/el/gnus/lisp/gnus-win hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-win
~/Repos/el/gnus/lisp/gnus-async hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-async
~/Repos/el/gnus/lisp/mm-url hides /home/horn/Repos/el/emacs/lisp/gnus/mm-url
~/Repos/el/gnus/lisp/gnus-html hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-html
~/Repos/el/gnus/lisp/gssapi hides /home/horn/Repos/el/emacs/lisp/gnus/gssapi
~/Repos/el/gnus/lisp/mml2015 hides /home/horn/Repos/el/emacs/lisp/gnus/mml2015
~/Repos/el/gnus/lisp/nnrss hides /home/horn/Repos/el/emacs/lisp/gnus/nnrss
~/Repos/el/gnus/lisp/gnus-mh hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-mh
~/Repos/el/gnus/lisp/gnus-sum hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-sum
~/Repos/el/gnus/lisp/nnweb hides /home/horn/Repos/el/emacs/lisp/gnus/nnweb
~/Repos/el/gnus/lisp/mail-prsvr hides /home/horn/Repos/el/emacs/lisp/gnus/mail-prsvr
~/Repos/el/gnus/lisp/nnmairix hides /home/horn/Repos/el/emacs/lisp/gnus/nnmairix
~/Repos/el/gnus/lisp/plstore hides /home/horn/Repos/el/emacs/lisp/gnus/plstore
~/Repos/el/gnus/lisp/rfc2045 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2045
~/Repos/el/gnus/lisp/gnus-msg hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-msg
~/Repos/el/gnus/lisp/spam-wash hides /home/horn/Repos/el/emacs/lisp/gnus/spam-wash
~/Repos/el/gnus/lisp/gnus-score hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-score
~/Repos/el/gnus/lisp/mm-uu hides /home/horn/Repos/el/emacs/lisp/gnus/mm-uu
~/Repos/el/gnus/lisp/spam hides /home/horn/Repos/el/emacs/lisp/gnus/spam
~/Repos/el/gnus/lisp/mm-view hides /home/horn/Repos/el/emacs/lisp/gnus/mm-view
~/Repos/el/gnus/lisp/sieve-mode hides /home/horn/Repos/el/emacs/lisp/gnus/sieve-mode
~/Repos/el/gnus/lisp/html2text hides /home/horn/Repos/el/emacs/lisp/gnus/html2text
~/Repos/el/gnus/lisp/gnus-ems hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-ems
~/Repos/el/gnus/lisp/registry hides /home/horn/Repos/el/emacs/lisp/gnus/registry
~/Repos/el/gnus/lisp/auth-source hides /home/horn/Repos/el/emacs/lisp/gnus/auth-source
~/Repos/el/gnus/lisp/gravatar hides /home/horn/Repos/el/emacs/lisp/gnus/gravatar
~/Repos/el/gnus/lisp/flow-fill hides /home/horn/Repos/el/emacs/lisp/gnus/flow-fill
~/Repos/el/gnus/lisp/gmm-utils hides /home/horn/Repos/el/emacs/lisp/gnus/gmm-utils
~/Repos/el/gnus/lisp/mailcap hides /home/horn/Repos/el/emacs/lisp/gnus/mailcap
~/Repos/el/gnus/lisp/gnus-delay hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-delay
~/Repos/el/gnus/lisp/mm-bodies hides /home/horn/Repos/el/emacs/lisp/gnus/mm-bodies
~/Repos/el/gnus/lisp/mm-archive hides /home/horn/Repos/el/emacs/lisp/gnus/mm-archive
~/Repos/el/gnus/lisp/rfc1843 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc1843
~/Repos/el/gnus/lisp/gnus-kill hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-kill
~/Repos/el/gnus/lisp/qp hides /home/horn/Repos/el/emacs/lisp/gnus/qp
~/Repos/el/gnus/lisp/score-mode hides /home/horn/Repos/el/emacs/lisp/gnus/score-mode
~/Repos/el/gnus/lisp/gnus-topic hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-topic
~/Repos/el/gnus/lisp/gnus-cache hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cache
~/Repos/el/gnus/lisp/nnmail hides /home/horn/Repos/el/emacs/lisp/gnus/nnmail
~/Repos/el/gnus/lisp/gnus-vm hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-vm
~/Repos/el/gnus/lisp/gnus-sync hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-sync
~/Repos/el/gnus/lisp/nnoo hides /home/horn/Repos/el/emacs/lisp/gnus/nnoo
~/Repos/el/gnus/lisp/nnregistry hides /home/horn/Repos/el/emacs/lisp/gnus/nnregistry
~/Repos/el/gnus/lisp/gnus-dup hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-dup
~/Repos/el/gnus/lisp/parse-time hides /home/horn/Repos/el/emacs/lisp/calendar/parse-time
~/Repos/el/gnus/lisp/time-date hides /home/horn/Repos/el/emacs/lisp/calendar/time-date
Features:
(shadow emacsbug mailalias smtpmail sendmail eieio-opt speedbar sb-image
ezimage dframe debug sort smiley gnus-cite gnus-async gnus-bcklg qp
gnus-ml nndraft nnmh rot13 utf-7 gnutls network-stream nsm starttls nnml
nnnil gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-cache
gnus-demon nntp spam spam-stat gnus-uu yenc gnus-msg gnus-gravatar
mail-extr gravatar gnus-topic nnir gnus-registry registry eieio-compat
eieio-base th-private smex ido colir color pdf-sync pdf-annot
pdf-outline pdf-links pdf-history preview prv-emacs auto-dictionary
flyspell ispell tex-buf reftex-dcr reftex-auc reftex reftex-vars
font-latex latex tex-style tex dbus tex-mode dired-aux gnus-dired
hl-line autorevert vc vc-dispatcher vc-git company-files company-oddmuse
company-keywords company-etags company-gtags company-dabbrev-code
company-dabbrev company-capf company-cmake company-xcode company-clang
company-semantic company-eclim company-template company-css company-nxml
company-bbdb company stratego-mode greql-mode tg-mode generic
preview-latex tex-site auto-loads cider cider-debug cider-browse-ns
cider-inspector cider-mode cider-repl cider-eldoc cider-interaction
arc-mode archive-mode cider-overlays cider-doc org-table org org-macro
org-footnote org-pcomplete org-list org-faces org-entities org-version
ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys
ob-comint ob-core ob-eval org-compat org-macs org-loaddefs find-func
cal-menu calendar cal-loaddefs cider-test cider-stacktrace cider-client
nrepl-client queue cider-util ewoc etags xref project clojure-mode
paredit aggressive-indent epa-file epa epg rdictcc
google-contacts-message google-contacts derived xml url-cache
google-oauth google-contacts-gnus gnus-art mm-uu mml2015 mm-view
mml-smime smime dig gnus-sum gnus-group gnus-undo gnus-start gnus-cloud
nnimap nnmail mail-source tls utf7 netrc nnoo parse-time gnus-spec
gnus-int gnus-range gnus-win gnus gnus-ems gnus-compat url url-proxy
url-privacy url-expand url-methods url-history url-cookie url-domsuf
url-util url-parse url-vars mailcap nnheader dired-x em-term term ehelp
esh-opt esh-ext esh-util highlight-symbol thingatpt boxquote rect
ecomplete yasnippet disp-table noutline outline pdf-occur ibuf-ext
ibuffer tablist tablist-filter semantic/wisent/comp semantic/wisent
semantic/wisent/wisent semantic/util-modes semantic/util semantic
semantic/tag semantic/lex semantic/fw mode-local cedet pdf-isearch
let-alist pdf-misc imenu pdf-tools compile cus-edit cus-start cus-load
pdf-view bookmark pp jka-compr pdf-cache pdf-info tq pdf-util image-mode
browse-kill-ring recentf tree-widget wid-edit highlight-parentheses cl
undo-tree diff iedit iedit-lib hydra lv counsel swiper cap-words
superword subword saveplace savehist paren ivy delsel icomplete mb-depth
ace-window avy magit-filenotify filenotify magit-blame magit-stash
magit-bisect magit-remote magit-commit magit-sequence magit magit-apply
magit-wip magit-log magit-diff smerge-mode diff-mode magit-core
magit-process magit-popup magit-mode magit-git crm magit-section
magit-utils git-commit log-edit easy-mmode message dired rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev mail-utils gmm-utils mailheader pcvs-util add-log
with-editor async-bytecomp async tramp-sh tramp tramp-compat auth-source
eieio byte-opt bytecomp byte-compile cl-extra seq cconv eieio-core
cl-macs gv gnus-util mm-util help-fns help-mode mail-prsvr
password-cache tramp-loaddefs trampver shell pcomplete comint ansi-color
ring format-spec server dash smart-mode-line-respectful-theme
smart-mode-line-light-theme cl-seq smart-mode-line rich-minority desktop
frameset rx bs elec-pair edmacro kmacro cl-loaddefs cl-lib gnus-load
subr-x pcase tsdh-light-theme finder-inf memory-usage-autoloads advice
info package easymenu epg-config time-date mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
dbusbind inotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 16 761839 123735)
(symbols 48 61156 14)
(miscs 40 401 732)
(strings 32 197644 64740)
(string-bytes 1 6690773)
(vectors 16 59047)
(vector-slots 8 1255728 44619)
(floats 8 1013 773)
(intervals 56 10043 2493)
(buffers 976 47)
(heap 1024 95606 10707))
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
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
0 siblings, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-09-09 20:43 UTC (permalink / raw)
To: 21313
This problem has nothing to to with dbus in particular. Today I had a
different occurrence of the bug where during repeated killing in a
message-mode buffer I suddenly got an error about something with a
file-notify event. I've stopped killing then just to read the error
message, and then I restarted killing which out of sudden made emacs
crash.
Since then I've let emacs run in the debugger. Just right now I had
another crash during repeated killing in message-mode, and below is the
backtrace.
To me that backtrace looks like there's a bug in the error printing code
which seems to cause the crashes. But it does not explain the source of
the errors I sometimes get during pressing and holding C-k in
message-mode. Those errors always sound as if events of the wrong kind
have been delegated to some event handlers, e.g., `dbus-handle-event'
might have received some file-notify event or `file-notify-handle-event'
might have received some keyboard event.
Any ideas how to debug that? The problem is that it is not really
reproducible, it just happens once every second day or so.
--8<---------------cut here---------------start------------->8---
Program received signal SIGSEGV, Segmentation fault.
0x000000000054ab2f in SYMBOL_INTERNED_P (sym=185795904) at lisp.h:1770
1770 return XSYMBOL (sym)->interned != SYMBOL_UNINTERNED;
(gdb) bt full
#0 0x000000000054ab2f in SYMBOL_INTERNED_P (sym=185795904) at lisp.h:1770
No locals.
#1 0x0000000000610588 in print_preprocess (obj=185795904) at print.c:1179
i = 0
size = 0
loop_count = 0
halftail = 185795904
#2 0x0000000000610328 in print (obj=185795904, printcharfun=43968, escapeflag=true)
at print.c:1116
No locals.
#3 0x000000000060df75 in Fprin1 (object=185795904, printcharfun=43968) at print.c:626
old = 0xaecc460
old_point = -1
start_point = -1
old_point_byte = -1
start_point_byte = -1
specpdl_count = 3
free_print_buffer = false
multibyte = true
original = 43968
#4 0x000000000060fead in print_error_message (data=86346515, stream=43968,
context=0xbe1a9f <pure+2999999> "", caller=23712) at print.c:946
obj = 185795904
sep = 0x6b806f ", "
errname = 50304
errmsg = 9499852
file_error = 0
tail = 86346563
#5 0x000000000055226d in Fcommand_error_default_function (data=86346515,
context=9458692, signal=23712) at keyboard.c:1026
sf = 0x129aca0
#6 0x00000000005ec8f8 in Ffuncall (nargs=4, args=0x7ffe058b14b0) at eval.c:2641
internal_argbuf = {0, 0, 140728991421808, 5581510, 0, 5581464, 9458692,
140728991421504}
fun = 9446293
original_fun = 321456
funcar = 9458692
numargs = 3
lisp_numargs = 5547072
val = 23712
internal_args = 0x7ffe058b14b8
count = 2
#7 0x00000000005ec33d in call3 (fn=321456, arg1=86346515, arg2=9458692, arg3=23712)
at eval.c:2509
No locals.
#8 0x0000000000552105 in cmd_error_internal (data=86346515, context=0x7ffe058b1520 "")
at keyboard.c:981
No locals.
#9 0x0000000000552019 in cmd_error (data=86346515) at keyboard.c:950
old_level = 0
old_length = 0
macroerror = "\000\000\000\000\000\000\000\000\256\254^\000\000\000\000\000\000\000\000\000\001\000\000\000\203j\021\001\000\000\000\000\260\323\306\000\000\000\000\000`\304\354\n\000\000\000\000A\001"
#10 0x00000000005e9656 in internal_condition_case (bfun=0x5526bc <command_loop_1>,
---Type <return> to continue, or q <return> to quit---
handlers=18912, hfun=0x551ea6 <cmd_error>) at eval.c:1290
val = 86346515
val = 5546463
c = 0x1542ca0
#11 0x00000000005523c3 in command_loop_2 (ignore=0) at keyboard.c:1088
val = 2
#12 0x00000000005e8e20 in internal_catch (tag=45312, func=0x55239a <command_loop_2>,
arg=0) at eval.c:1057
val = 5546463
c = 0x1542b70
#13 0x0000000000552365 in command_loop () at keyboard.c:1067
No locals.
#14 0x0000000000551a6e in recursive_edit_1 () at keyboard.c:673
count = 1
val = 140728991422112
#15 0x0000000000551c02 in Frecursive_edit () at keyboard.c:744
count = 0
buffer = 0
#16 0x000000000054fafd in main (argc=1, argv=0x7ffe058b18a8) at emacs.c:1643
dummy = 0
stack_bottom_variable = 0 '\000'
do_initial_setlocale = true
dumping = false
skip_args = 0
rlim = {
rlim_cur = 8720000,
rlim_max = 18446744073709551615
}
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = 0x0
Lisp Backtrace:
"command-error-default-function" (0x58b14b8)
(gdb)
--8<---------------cut here---------------end--------------->8---
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-09-09 20:43 ` Tassilo Horn
@ 2015-09-11 12:28 ` Tassilo Horn
2015-09-11 12:39 ` Eli Zaretskii
0 siblings, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-09-11 12:28 UTC (permalink / raw)
To: 21313
Just now, I had three other strange errors during killing in
message-mode. The first two were about errors in
`file-notify-handle-event' which was called with something wrong. With
the first error, it received a buffer (!) instead of an event, with the
second error I think it received something else which I can't remember.
At least it hasn't been a file-notification event.
Well, and then the third error crashed emacs. That's the reason why I
can't check the first two error messages anymore.
Here's the backtrace:
--8<---------------cut here---------------start------------->8---
Program received signal SIGSEGV, Segmentation fault.
mark_object (arg=100583123) at alloc.c:6187
6187 if (ptr->gcmarkbit)
(gdb) bt full
#0 mark_object (arg=100583123) at alloc.c:6187
ptr = 0x6c5a710
obj = 113616656
po = 0x6c5a710
cdr_count = 1
#1 0x0000000000566db8 in mark_kboards () at keyboard.c:11779
event = 0xc34018
kb = 0x0
p = 0xffffffffffffffff
#2 0x00000000005ca236 in garbage_collect_1 (end=0x7ffd186d1858) at alloc.c:5491
nextb = 0x0
stack_top_variable = 0 '\000'
i = 586
message_p = true
count = 49
start = {
tv_sec = 1441973881,
tv_nsec = 789497182
}
retval = 0
tot_before = 0
total = {12861664, 100207171, 8589978560, 0, 5546337, 2, 140725013256000, 6053356,
0, 83389008, 140725013256064}
#3 0x00000000005ca91c in Fgarbage_collect () at alloc.c:5720
end = 0x7ffd186d1858
#4 0x000000000054bfd4 in maybe_gc () at lisp.h:4515
No locals.
#5 0x00000000005ec53c in Ffuncall (nargs=4, args=0x7ffd186d1a40) at eval.c:2584
fun = 52936821
original_fun = 140725013256544
funcar = 1258525563571
numargs = 3
lisp_numargs = 5546337
val = 35181744
internal_args = 0x5f81ab3
count = 48
#6 0x00000000005ebc9c in funcall_nil (nargs=4, args=0x7ffd186d1a40) at eval.c:2273
No locals.
#7 0x00000000005ec09d in run_hook_with_args (nargs=4, args=0x7ffd186d1a40,
funcall=0x5ebc79 <funcall_nil>) at eval.c:2450
global_vals = 0
sym = 8976
val = 100145843
ret = 0
#8 0x00000000005ebd23 in Frun_hook_with_args (nargs=4, args=0x7ffd186d1a40) at eval.c:2315
No locals.
#9 0x000000000058a275 in signal_after_change (charpos=751, lendel=0, lenins=81)
at insdel.c:2066
count = 46
rvoe_arg = {
location = 0xc5cf80,
errorp = true
}
#10 0x000000000060e066 in Fprin1 (object=99359565, printcharfun=0) at print.c:627
old = 0x47b8670
old_point = -1
start_point = -1
---Type <return> to continue, or q <return> to quit---
old_point_byte = -1
start_point_byte = -1
specpdl_count = 45
free_print_buffer = true
multibyte = true
original = 75204213
#11 0x00000000005eddc1 in Fbacktrace () at eval.c:3231
i = 2
pdl = 0x2eb9070
tem = 374592
old_print_level = 34
#12 0x00000000005ec797 in Ffuncall (nargs=1, args=0x7ffd186d1c40) at eval.c:2631
internal_argbuf = {140725013257136, 6088326, 12873456, 75204208, 13033552,
75204213, 0, 13076080}
fun = 12490237
original_fun = 365424
funcar = 48993648
numargs = 0
lisp_numargs = 5546337
val = 43968
internal_args = 0x7ffd186d1c48
count = 44
#13 0x000000000062f86b in exec_byte_code (bytestr=64582260, vector=52936821, maxdepth=26,
args_template=1030, nargs=1, args=0x7ffd186d2268) at bytecode.c:880
targets = {0x632f6d <exec_byte_code+17119>, 0x632fcd <exec_byte_code+17215>,
0x632fcf <exec_byte_code+17217>, 0x632fd1 <exec_byte_code+17219>,
0x632fd3 <exec_byte_code+17221>, 0x632fd3 <exec_byte_code+17221>,
0x633033 <exec_byte_code+17317>, 0x6330a6 <exec_byte_code+17432>,
0x62f0f0 <exec_byte_code+1122>, 0x62f0f2 <exec_byte_code+1124>,
0x62f0f4 <exec_byte_code+1126>, 0x62f0f6 <exec_byte_code+1128>,
0x62f0f8 <exec_byte_code+1130>, 0x62f0f8 <exec_byte_code+1130>,
0x62f0fe <exec_byte_code+1136>, 0x62f0b3 <exec_byte_code+1061>,
0x62f575 <exec_byte_code+2279>, 0x62f577 <exec_byte_code+2281>,
0x62f579 <exec_byte_code+2283>, 0x62f57b <exec_byte_code+2285>,
0x62f57d <exec_byte_code+2287>, 0x62f57d <exec_byte_code+2287>,
0x62f5be <exec_byte_code+2352>, 0x62f583 <exec_byte_code+2293>,
0x62f776 <exec_byte_code+2792>, 0x62f778 <exec_byte_code+2794>,
0x62f77a <exec_byte_code+2796>, 0x62f77c <exec_byte_code+2798>,
0x62f77e <exec_byte_code+2800>, 0x62f77e <exec_byte_code+2800>,
0x62f71e <exec_byte_code+2704>, 0x62f73b <exec_byte_code+2733>,
0x62f838 <exec_byte_code+2986>, 0x62f83a <exec_byte_code+2988>,
0x62f83c <exec_byte_code+2990>, 0x62f83e <exec_byte_code+2992>,
0x62f840 <exec_byte_code+2994>, 0x62f840 <exec_byte_code+2994>,
0x62f7e0 <exec_byte_code+2898>, 0x62f7fd <exec_byte_code+2927>,
0x62f8fa <exec_byte_code+3180>, 0x62f8fc <exec_byte_code+3182>,
0x62f8fe <exec_byte_code+3184>, 0x62f900 <exec_byte_code+3186>,
0x62f902 <exec_byte_code+3188>, 0x62f902 <exec_byte_code+3188>,
0x62f8a2 <exec_byte_code+3092>, 0x62f8bf <exec_byte_code+3121>,
0x6309b7 <exec_byte_code+7465>, 0x63078c <exec_byte_code+6910>,
0x630783 <exec_byte_code+6901>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x630bdd <exec_byte_code+8015>, 0x630cb6 <exec_byte_code+8232>,
0x630d14 <exec_byte_code+8326>, 0x630d73 <exec_byte_code+8421>,
0x630dd6 <exec_byte_code+8520>, 0x62f3ef <exec_byte_code+1889>,
0x62f465 <exec_byte_code+2007>, 0x630e4b <exec_byte_code+8637>,
0x62f346 <exec_byte_code+1720>, 0x62f4cb <exec_byte_code+2109>,
---Type <return> to continue, or q <return> to quit---
0x630eb1 <exec_byte_code+8739>, 0x630f17 <exec_byte_code+8841>,
0x630f5d <exec_byte_code+8911>, 0x630fc3 <exec_byte_code+9013>,
0x631010 <exec_byte_code+9090>, 0x6310dd <exec_byte_code+9295>,
0x631123 <exec_byte_code+9365>, 0x631189 <exec_byte_code+9467>,
0x63120c <exec_byte_code+9598>, 0x631252 <exec_byte_code+9668>,
0x631298 <exec_byte_code+9738>, 0x6312fe <exec_byte_code+9840>,
0x631364 <exec_byte_code+9942>, 0x6313ca <exec_byte_code+10044>,
0x63144d <exec_byte_code+10175>, 0x63149a <exec_byte_code+10252>,
0x6314e7 <exec_byte_code+10329>, 0x6315b4 <exec_byte_code+10534>,
0x631645 <exec_byte_code+10679>, 0x6316d6 <exec_byte_code+10824>,
0x631927 <exec_byte_code+11417>, 0x631992 <exec_byte_code+11524>,
0x6319fd <exec_byte_code+11631>, 0x631a68 <exec_byte_code+11738>,
0x631ad3 <exec_byte_code+11845>, 0x631b20 <exec_byte_code+11922>,
0x631bb2 <exec_byte_code+12068>, 0x631bff <exec_byte_code+12145>,
0x631c4c <exec_byte_code+12222>, 0x631c99 <exec_byte_code+12299>,
0x631d99 <exec_byte_code+12555>, 0x630620 <exec_byte_code+6546>,
0x631df6 <exec_byte_code+12648>, 0x631e3c <exec_byte_code+12718>,
0x631f04 <exec_byte_code+12918>, 0x631f61 <exec_byte_code+13011>,
0x631fbe <exec_byte_code+13104>, 0x632004 <exec_byte_code+13174>,
0x632050 <exec_byte_code+13250>, 0x63209c <exec_byte_code+13326>,
0x6320f0 <exec_byte_code+13410>, 0x632f6d <exec_byte_code+17119>,
0x632146 <exec_byte_code+13496>, 0x632187 <exec_byte_code+13561>,
0x6321c8 <exec_byte_code+13626>, 0x632209 <exec_byte_code+13691>,
0x63224a <exec_byte_code+13756>, 0x63228b <exec_byte_code+13821>,
0x630620 <exec_byte_code+6546>, 0x632f6d <exec_byte_code+17119>,
0x6322d1 <exec_byte_code+13891>, 0x63231f <exec_byte_code+13969>,
0x632365 <exec_byte_code+14039>, 0x6323ab <exec_byte_code+14109>,
0x632411 <exec_byte_code+14211>, 0x632477 <exec_byte_code+14313>,
0x6324bd <exec_byte_code+14383>, 0x6325ad <exec_byte_code+14623>,
0x632613 <exec_byte_code+14725>, 0x632679 <exec_byte_code+14827>,
0x6326df <exec_byte_code+14929>, 0x632720 <exec_byte_code+14994>,
0x632f6d <exec_byte_code+17119>, 0x630557 <exec_byte_code+6345>,
0x62f9a7 <exec_byte_code+3353>, 0x62f1e6 <exec_byte_code+1368>,
0x62fada <exec_byte_code+3660>, 0x62fc3a <exec_byte_code+4012>,
0x62fd8e <exec_byte_code+4352>, 0x6304e8 <exec_byte_code+6234>,
0x630525 <exec_byte_code+6295>, 0x62f6d0 <exec_byte_code+2626>,
0x6305e1 <exec_byte_code+6483>, 0x630652 <exec_byte_code+6596>,
0x6306dc <exec_byte_code+6734>, 0x63071b <exec_byte_code+6797>,
0x6309f6 <exec_byte_code+7528>, 0x630a78 <exec_byte_code+7658>,
0x630afb <exec_byte_code+7789>, 0x630b5c <exec_byte_code+7886>,
0x62f95e <exec_byte_code+3280>, 0x632766 <exec_byte_code+15064>,
0x6327e9 <exec_byte_code+15195>, 0x63282f <exec_byte_code+15265>,
0x632875 <exec_byte_code+15335>, 0x6328bb <exec_byte_code+15405>,
0x632901 <exec_byte_code+15475>, 0x632967 <exec_byte_code+15577>,
0x6329cd <exec_byte_code+15679>, 0x632a33 <exec_byte_code+15781>,
0x632a99 <exec_byte_code+15883>, 0x632bd8 <exec_byte_code+16202>,
0x632c3e <exec_byte_code+16304>, 0x632ca4 <exec_byte_code+16406>,
0x632cea <exec_byte_code+16476>, 0x632d50 <exec_byte_code+16578>,
0x632db6 <exec_byte_code+16680>, 0x632e0a <exec_byte_code+16764>,
0x632e5e <exec_byte_code+16848>, 0x631ce6 <exec_byte_code+12376>,
0x631d33 <exec_byte_code+12453>, 0x632eab <exec_byte_code+16925>,
0x632f0e <exec_byte_code+17024>, 0x632f6d <exec_byte_code+17119>,
0x62fee2 <exec_byte_code+4692>, 0x62ffe8 <exec_byte_code+4954>,
0x63012d <exec_byte_code+5279>, 0x630272 <exec_byte_code+5604>,
0x6303ad <exec_byte_code+5919>, 0x63105d <exec_byte_code+9167>,
0x631534 <exec_byte_code+10406>, 0x631e84 <exec_byte_code+12790>,
0x633140 <exec_byte_code+17586>, 0x6331b6 <exec_byte_code+17704>,
---Type <return> to continue, or q <return> to quit---
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x633253 <exec_byte_code+17861>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x6332db <exec_byte_code+17997> <repeats 64 times>}
count = 40
op = 0
vectorp = 0x327c078
stack = {
pc = 0x519da9d "\210,eb\210`\315\316!\210\001@\317=\203*",
byte_string = 64582260,
byte_string_start = 0x519da88 "\306\020\307 \210\310\311!\210\311\021p\311\312\313\032\033\034\035\314 \210,eb\210`\315\316!\210\001@\317=\203*",
next = 0x7ffd186d22f0
}
top = 0x7ffd186d1c40
result = 0
type = (CONDITION_CASE | unknown: 32764)
#14 0x00000000005ecfc1 in funcall_lambda (fun=66253821, nargs=1, arg_vector=0x7ffd186d2260)
at eval.c:2794
val = 1
syms_left = 1030
next = 3745920
lexenv = 51949412480
count = 40
i = 5550624
optional = false
rest = false
#15 0x00000000005eca3e in Ffuncall (nargs=2, args=0x7ffd186d2258) at eval.c:2683
fun = 66253821
original_fun = 16940208
funcar = 5546541
numargs = 1
lisp_numargs = 13033552
val = 46608
internal_args = 0x5cdb43 <Fsetcar+118>
count = 39
#16 0x000000000062f86b in exec_byte_code (bytestr=64612244, vector=94525885, maxdepth=166,
args_template=514, nargs=2, args=0x7ffd186d27a8) at bytecode.c:880
targets = {0x632f6d <exec_byte_code+17119>, 0x632fcd <exec_byte_code+17215>,
0x632fcf <exec_byte_code+17217>, 0x632fd1 <exec_byte_code+17219>,
0x632fd3 <exec_byte_code+17221>, 0x632fd3 <exec_byte_code+17221>,
0x633033 <exec_byte_code+17317>, 0x6330a6 <exec_byte_code+17432>,
0x62f0f0 <exec_byte_code+1122>, 0x62f0f2 <exec_byte_code+1124>,
0x62f0f4 <exec_byte_code+1126>, 0x62f0f6 <exec_byte_code+1128>,
0x62f0f8 <exec_byte_code+1130>, 0x62f0f8 <exec_byte_code+1130>,
0x62f0fe <exec_byte_code+1136>, 0x62f0b3 <exec_byte_code+1061>,
0x62f575 <exec_byte_code+2279>, 0x62f577 <exec_byte_code+2281>,
0x62f579 <exec_byte_code+2283>, 0x62f57b <exec_byte_code+2285>,
0x62f57d <exec_byte_code+2287>, 0x62f57d <exec_byte_code+2287>,
0x62f5be <exec_byte_code+2352>, 0x62f583 <exec_byte_code+2293>,
0x62f776 <exec_byte_code+2792>, 0x62f778 <exec_byte_code+2794>,
0x62f77a <exec_byte_code+2796>, 0x62f77c <exec_byte_code+2798>,
0x62f77e <exec_byte_code+2800>, 0x62f77e <exec_byte_code+2800>,
0x62f71e <exec_byte_code+2704>, 0x62f73b <exec_byte_code+2733>,
---Type <return> to continue, or q <return> to quit---
0x62f838 <exec_byte_code+2986>, 0x62f83a <exec_byte_code+2988>,
0x62f83c <exec_byte_code+2990>, 0x62f83e <exec_byte_code+2992>,
0x62f840 <exec_byte_code+2994>, 0x62f840 <exec_byte_code+2994>,
0x62f7e0 <exec_byte_code+2898>, 0x62f7fd <exec_byte_code+2927>,
0x62f8fa <exec_byte_code+3180>, 0x62f8fc <exec_byte_code+3182>,
0x62f8fe <exec_byte_code+3184>, 0x62f900 <exec_byte_code+3186>,
0x62f902 <exec_byte_code+3188>, 0x62f902 <exec_byte_code+3188>,
0x62f8a2 <exec_byte_code+3092>, 0x62f8bf <exec_byte_code+3121>,
0x6309b7 <exec_byte_code+7465>, 0x63078c <exec_byte_code+6910>,
0x630783 <exec_byte_code+6901>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x630bdd <exec_byte_code+8015>, 0x630cb6 <exec_byte_code+8232>,
0x630d14 <exec_byte_code+8326>, 0x630d73 <exec_byte_code+8421>,
0x630dd6 <exec_byte_code+8520>, 0x62f3ef <exec_byte_code+1889>,
0x62f465 <exec_byte_code+2007>, 0x630e4b <exec_byte_code+8637>,
0x62f346 <exec_byte_code+1720>, 0x62f4cb <exec_byte_code+2109>,
0x630eb1 <exec_byte_code+8739>, 0x630f17 <exec_byte_code+8841>,
0x630f5d <exec_byte_code+8911>, 0x630fc3 <exec_byte_code+9013>,
0x631010 <exec_byte_code+9090>, 0x6310dd <exec_byte_code+9295>,
0x631123 <exec_byte_code+9365>, 0x631189 <exec_byte_code+9467>,
0x63120c <exec_byte_code+9598>, 0x631252 <exec_byte_code+9668>,
0x631298 <exec_byte_code+9738>, 0x6312fe <exec_byte_code+9840>,
0x631364 <exec_byte_code+9942>, 0x6313ca <exec_byte_code+10044>,
0x63144d <exec_byte_code+10175>, 0x63149a <exec_byte_code+10252>,
0x6314e7 <exec_byte_code+10329>, 0x6315b4 <exec_byte_code+10534>,
0x631645 <exec_byte_code+10679>, 0x6316d6 <exec_byte_code+10824>,
0x631927 <exec_byte_code+11417>, 0x631992 <exec_byte_code+11524>,
0x6319fd <exec_byte_code+11631>, 0x631a68 <exec_byte_code+11738>,
0x631ad3 <exec_byte_code+11845>, 0x631b20 <exec_byte_code+11922>,
0x631bb2 <exec_byte_code+12068>, 0x631bff <exec_byte_code+12145>,
0x631c4c <exec_byte_code+12222>, 0x631c99 <exec_byte_code+12299>,
0x631d99 <exec_byte_code+12555>, 0x630620 <exec_byte_code+6546>,
0x631df6 <exec_byte_code+12648>, 0x631e3c <exec_byte_code+12718>,
0x631f04 <exec_byte_code+12918>, 0x631f61 <exec_byte_code+13011>,
0x631fbe <exec_byte_code+13104>, 0x632004 <exec_byte_code+13174>,
0x632050 <exec_byte_code+13250>, 0x63209c <exec_byte_code+13326>,
0x6320f0 <exec_byte_code+13410>, 0x632f6d <exec_byte_code+17119>,
0x632146 <exec_byte_code+13496>, 0x632187 <exec_byte_code+13561>,
0x6321c8 <exec_byte_code+13626>, 0x632209 <exec_byte_code+13691>,
0x63224a <exec_byte_code+13756>, 0x63228b <exec_byte_code+13821>,
0x630620 <exec_byte_code+6546>, 0x632f6d <exec_byte_code+17119>,
0x6322d1 <exec_byte_code+13891>, 0x63231f <exec_byte_code+13969>,
0x632365 <exec_byte_code+14039>, 0x6323ab <exec_byte_code+14109>,
0x632411 <exec_byte_code+14211>, 0x632477 <exec_byte_code+14313>,
0x6324bd <exec_byte_code+14383>, 0x6325ad <exec_byte_code+14623>,
0x632613 <exec_byte_code+14725>, 0x632679 <exec_byte_code+14827>,
0x6326df <exec_byte_code+14929>, 0x632720 <exec_byte_code+14994>,
0x632f6d <exec_byte_code+17119>, 0x630557 <exec_byte_code+6345>,
0x62f9a7 <exec_byte_code+3353>, 0x62f1e6 <exec_byte_code+1368>,
0x62fada <exec_byte_code+3660>, 0x62fc3a <exec_byte_code+4012>,
0x62fd8e <exec_byte_code+4352>, 0x6304e8 <exec_byte_code+6234>,
0x630525 <exec_byte_code+6295>, 0x62f6d0 <exec_byte_code+2626>,
0x6305e1 <exec_byte_code+6483>, 0x630652 <exec_byte_code+6596>,
0x6306dc <exec_byte_code+6734>, 0x63071b <exec_byte_code+6797>,
0x6309f6 <exec_byte_code+7528>, 0x630a78 <exec_byte_code+7658>,
0x630afb <exec_byte_code+7789>, 0x630b5c <exec_byte_code+7886>,
---Type <return> to continue, or q <return> to quit---
0x62f95e <exec_byte_code+3280>, 0x632766 <exec_byte_code+15064>,
0x6327e9 <exec_byte_code+15195>, 0x63282f <exec_byte_code+15265>,
0x632875 <exec_byte_code+15335>, 0x6328bb <exec_byte_code+15405>,
0x632901 <exec_byte_code+15475>, 0x632967 <exec_byte_code+15577>,
0x6329cd <exec_byte_code+15679>, 0x632a33 <exec_byte_code+15781>,
0x632a99 <exec_byte_code+15883>, 0x632bd8 <exec_byte_code+16202>,
0x632c3e <exec_byte_code+16304>, 0x632ca4 <exec_byte_code+16406>,
0x632cea <exec_byte_code+16476>, 0x632d50 <exec_byte_code+16578>,
0x632db6 <exec_byte_code+16680>, 0x632e0a <exec_byte_code+16764>,
0x632e5e <exec_byte_code+16848>, 0x631ce6 <exec_byte_code+12376>,
0x631d33 <exec_byte_code+12453>, 0x632eab <exec_byte_code+16925>,
0x632f0e <exec_byte_code+17024>, 0x632f6d <exec_byte_code+17119>,
0x62fee2 <exec_byte_code+4692>, 0x62ffe8 <exec_byte_code+4954>,
0x63012d <exec_byte_code+5279>, 0x630272 <exec_byte_code+5604>,
0x6303ad <exec_byte_code+5919>, 0x63105d <exec_byte_code+9167>,
0x631534 <exec_byte_code+10406>, 0x631e84 <exec_byte_code+12790>,
0x633140 <exec_byte_code+17586>, 0x6331b6 <exec_byte_code+17704>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x633253 <exec_byte_code+17861>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x6332db <exec_byte_code+17997> <repeats 64 times>}
count = 13
op = 1
vectorp = 0x5a259c0
stack = {
pc = 0x519d8da "\210\n\203d\001\353ed\"\016KV\203W\001eb\210\354\016K\245y\210`db\210\354\016K\245\016KZy\210\211`|\266\002\355c\210eb\210\306\356\313 \"\210\357\360!\210\306\361!\210\310\317\036L\036:\306\361!\210\212\362 \210.\026\266\022\016\064\026M\t.\a\207",
byte_string = 64612244,
byte_string_start = 0x519d7b0 "\b\203\006",
next = 0x7ffd186d2ac0
}
top = 0x7ffd186d2258
result = 13033552
type = (CONDITION_CASE | unknown: 32764)
#17 0x00000000005ecfc1 in funcall_lambda (fun=89315813, nargs=2, arg_vector=0x7ffd186d27a8)
at eval.c:2794
val = 2
syms_left = 514
next = 63019193
lexenv = 51949414080
count = 13
i = 5550624
optional = false
rest = false
#18 0x00000000005eca3e in Ffuncall (nargs=3, args=0x7ffd186d27a0) at eval.c:2683
fun = 89315813
original_fun = 16464
funcar = 0
numargs = 2
lisp_numargs = 13033552
val = 0
internal_args = 0xa3a6c5bf0
count = 12
---Type <return> to continue, or q <return> to quit---
#19 0x00000000005ebc42 in Fapply (nargs=2, args=0x7ffd186d2860) at eval.c:2262
i = 3
numargs = 2
funcall_nargs = 3
funcall_args = 0x7ffd186d27a0
spread_arg = 0
fun = 89315813
retval = 140725013260288
sa_avail = 16360
sa_count = 12
sa_must_free = false
#20 0x00000000005ec193 in apply1 (fn=16464, arg=100154467) at eval.c:2478
No locals.
#21 0x00000000005e7595 in call_debugger (arg=100154467) at eval.c:308
debug_while_redisplaying = false
count = 8
val = 140725013260464
old_depth = 800
old_max = 1300
#22 0x00000000005ea298 in maybe_call_debugger (conditions=9509227, sig=21360,
data=100156147) at eval.c:1671
combined_data = 100156163
#23 0x00000000005e9d4a in Fsignal (error_symbol=21360, data=100156147) at eval.c:1489
debugger_called = false
conditions = 9509227
string = 5550624
real_error_symbol = 21360
clause = 43968
h = 0x14e7da0
#24 0x00000000005ec7ef in Ffuncall (nargs=3, args=0x7ffd186d2a60) at eval.c:2637
internal_argbuf = {0, 0, 13033552, 0, 0, 100156147, 140725013260800, 5546582}
fun = 12489469
original_fun = 42096
funcar = 100156147
numargs = 2
lisp_numargs = 100156099
val = 0
internal_args = 0x7ffd186d2a68
count = 7
#25 0x000000000062f86b in exec_byte_code (bytestr=63296212, vector=93888725, maxdepth=22,
args_template=1030, nargs=1, args=0x7ffd186d3068) at bytecode.c:880
targets = {0x632f6d <exec_byte_code+17119>, 0x632fcd <exec_byte_code+17215>,
0x632fcf <exec_byte_code+17217>, 0x632fd1 <exec_byte_code+17219>,
0x632fd3 <exec_byte_code+17221>, 0x632fd3 <exec_byte_code+17221>,
0x633033 <exec_byte_code+17317>, 0x6330a6 <exec_byte_code+17432>,
0x62f0f0 <exec_byte_code+1122>, 0x62f0f2 <exec_byte_code+1124>,
0x62f0f4 <exec_byte_code+1126>, 0x62f0f6 <exec_byte_code+1128>,
0x62f0f8 <exec_byte_code+1130>, 0x62f0f8 <exec_byte_code+1130>,
0x62f0fe <exec_byte_code+1136>, 0x62f0b3 <exec_byte_code+1061>,
0x62f575 <exec_byte_code+2279>, 0x62f577 <exec_byte_code+2281>,
0x62f579 <exec_byte_code+2283>, 0x62f57b <exec_byte_code+2285>,
0x62f57d <exec_byte_code+2287>, 0x62f57d <exec_byte_code+2287>,
0x62f5be <exec_byte_code+2352>, 0x62f583 <exec_byte_code+2293>,
0x62f776 <exec_byte_code+2792>, 0x62f778 <exec_byte_code+2794>,
0x62f77a <exec_byte_code+2796>, 0x62f77c <exec_byte_code+2798>,
0x62f77e <exec_byte_code+2800>, 0x62f77e <exec_byte_code+2800>,
0x62f71e <exec_byte_code+2704>, 0x62f73b <exec_byte_code+2733>,
---Type <return> to continue, or q <return> to quit---
0x62f838 <exec_byte_code+2986>, 0x62f83a <exec_byte_code+2988>,
0x62f83c <exec_byte_code+2990>, 0x62f83e <exec_byte_code+2992>,
0x62f840 <exec_byte_code+2994>, 0x62f840 <exec_byte_code+2994>,
0x62f7e0 <exec_byte_code+2898>, 0x62f7fd <exec_byte_code+2927>,
0x62f8fa <exec_byte_code+3180>, 0x62f8fc <exec_byte_code+3182>,
0x62f8fe <exec_byte_code+3184>, 0x62f900 <exec_byte_code+3186>,
0x62f902 <exec_byte_code+3188>, 0x62f902 <exec_byte_code+3188>,
0x62f8a2 <exec_byte_code+3092>, 0x62f8bf <exec_byte_code+3121>,
0x6309b7 <exec_byte_code+7465>, 0x63078c <exec_byte_code+6910>,
0x630783 <exec_byte_code+6901>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x630bdd <exec_byte_code+8015>, 0x630cb6 <exec_byte_code+8232>,
0x630d14 <exec_byte_code+8326>, 0x630d73 <exec_byte_code+8421>,
0x630dd6 <exec_byte_code+8520>, 0x62f3ef <exec_byte_code+1889>,
0x62f465 <exec_byte_code+2007>, 0x630e4b <exec_byte_code+8637>,
0x62f346 <exec_byte_code+1720>, 0x62f4cb <exec_byte_code+2109>,
0x630eb1 <exec_byte_code+8739>, 0x630f17 <exec_byte_code+8841>,
0x630f5d <exec_byte_code+8911>, 0x630fc3 <exec_byte_code+9013>,
0x631010 <exec_byte_code+9090>, 0x6310dd <exec_byte_code+9295>,
0x631123 <exec_byte_code+9365>, 0x631189 <exec_byte_code+9467>,
0x63120c <exec_byte_code+9598>, 0x631252 <exec_byte_code+9668>,
0x631298 <exec_byte_code+9738>, 0x6312fe <exec_byte_code+9840>,
0x631364 <exec_byte_code+9942>, 0x6313ca <exec_byte_code+10044>,
0x63144d <exec_byte_code+10175>, 0x63149a <exec_byte_code+10252>,
0x6314e7 <exec_byte_code+10329>, 0x6315b4 <exec_byte_code+10534>,
0x631645 <exec_byte_code+10679>, 0x6316d6 <exec_byte_code+10824>,
0x631927 <exec_byte_code+11417>, 0x631992 <exec_byte_code+11524>,
0x6319fd <exec_byte_code+11631>, 0x631a68 <exec_byte_code+11738>,
0x631ad3 <exec_byte_code+11845>, 0x631b20 <exec_byte_code+11922>,
0x631bb2 <exec_byte_code+12068>, 0x631bff <exec_byte_code+12145>,
0x631c4c <exec_byte_code+12222>, 0x631c99 <exec_byte_code+12299>,
0x631d99 <exec_byte_code+12555>, 0x630620 <exec_byte_code+6546>,
0x631df6 <exec_byte_code+12648>, 0x631e3c <exec_byte_code+12718>,
0x631f04 <exec_byte_code+12918>, 0x631f61 <exec_byte_code+13011>,
0x631fbe <exec_byte_code+13104>, 0x632004 <exec_byte_code+13174>,
0x632050 <exec_byte_code+13250>, 0x63209c <exec_byte_code+13326>,
0x6320f0 <exec_byte_code+13410>, 0x632f6d <exec_byte_code+17119>,
0x632146 <exec_byte_code+13496>, 0x632187 <exec_byte_code+13561>,
0x6321c8 <exec_byte_code+13626>, 0x632209 <exec_byte_code+13691>,
0x63224a <exec_byte_code+13756>, 0x63228b <exec_byte_code+13821>,
0x630620 <exec_byte_code+6546>, 0x632f6d <exec_byte_code+17119>,
0x6322d1 <exec_byte_code+13891>, 0x63231f <exec_byte_code+13969>,
0x632365 <exec_byte_code+14039>, 0x6323ab <exec_byte_code+14109>,
0x632411 <exec_byte_code+14211>, 0x632477 <exec_byte_code+14313>,
0x6324bd <exec_byte_code+14383>, 0x6325ad <exec_byte_code+14623>,
0x632613 <exec_byte_code+14725>, 0x632679 <exec_byte_code+14827>,
0x6326df <exec_byte_code+14929>, 0x632720 <exec_byte_code+14994>,
0x632f6d <exec_byte_code+17119>, 0x630557 <exec_byte_code+6345>,
0x62f9a7 <exec_byte_code+3353>, 0x62f1e6 <exec_byte_code+1368>,
0x62fada <exec_byte_code+3660>, 0x62fc3a <exec_byte_code+4012>,
0x62fd8e <exec_byte_code+4352>, 0x6304e8 <exec_byte_code+6234>,
0x630525 <exec_byte_code+6295>, 0x62f6d0 <exec_byte_code+2626>,
0x6305e1 <exec_byte_code+6483>, 0x630652 <exec_byte_code+6596>,
0x6306dc <exec_byte_code+6734>, 0x63071b <exec_byte_code+6797>,
0x6309f6 <exec_byte_code+7528>, 0x630a78 <exec_byte_code+7658>,
0x630afb <exec_byte_code+7789>, 0x630b5c <exec_byte_code+7886>,
---Type <return> to continue, or q <return> to quit---
0x62f95e <exec_byte_code+3280>, 0x632766 <exec_byte_code+15064>,
0x6327e9 <exec_byte_code+15195>, 0x63282f <exec_byte_code+15265>,
0x632875 <exec_byte_code+15335>, 0x6328bb <exec_byte_code+15405>,
0x632901 <exec_byte_code+15475>, 0x632967 <exec_byte_code+15577>,
0x6329cd <exec_byte_code+15679>, 0x632a33 <exec_byte_code+15781>,
0x632a99 <exec_byte_code+15883>, 0x632bd8 <exec_byte_code+16202>,
0x632c3e <exec_byte_code+16304>, 0x632ca4 <exec_byte_code+16406>,
0x632cea <exec_byte_code+16476>, 0x632d50 <exec_byte_code+16578>,
0x632db6 <exec_byte_code+16680>, 0x632e0a <exec_byte_code+16764>,
0x632e5e <exec_byte_code+16848>, 0x631ce6 <exec_byte_code+12376>,
0x631d33 <exec_byte_code+12453>, 0x632eab <exec_byte_code+16925>,
0x632f0e <exec_byte_code+17024>, 0x632f6d <exec_byte_code+17119>,
0x62fee2 <exec_byte_code+4692>, 0x62ffe8 <exec_byte_code+4954>,
0x63012d <exec_byte_code+5279>, 0x630272 <exec_byte_code+5604>,
0x6303ad <exec_byte_code+5919>, 0x63105d <exec_byte_code+9167>,
0x631534 <exec_byte_code+10406>, 0x631e84 <exec_byte_code+12790>,
0x633140 <exec_byte_code+17586>, 0x6331b6 <exec_byte_code+17704>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x633253 <exec_byte_code+17861>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x6332db <exec_byte_code+17997> <repeats 64 times>}
count = 7
op = 2
vectorp = 0x598a0d8
stack = {
pc = 0x480f834 "\207",
byte_string = 63296212,
byte_string_start = 0x480f818 "\211@\300=\203\026",
next = 0x7ffd186d33f0
}
top = 0x7ffd186d2a60
result = 579833618512
type = (CONDITION_CASE | unknown: 32764)
#26 0x00000000005ecfc1 in funcall_lambda (fun=93888781, nargs=1, arg_vector=0x7ffd186d3060)
at eval.c:2794
val = 1
syms_left = 1030
next = 0
lexenv = 51949416080
count = 7
i = 5550624
optional = false
rest = false
#27 0x00000000005eca3e in Ffuncall (nargs=2, args=0x7ffd186d3058) at eval.c:2683
fun = 93888781
original_fun = 531888
funcar = 6215718
numargs = 1
lisp_numargs = 140725013262128
val = 12488168
internal_args = 0x551dcb <temporarily_switch_to_single_kboard+162>
count = 6
#28 0x00000000005e4a02 in Ffuncall_interactively (nargs=2, args=0x7ffd186d3058)
at callint.c:250
---Type <return> to continue, or q <return> to quit---
speccount = 5
#29 0x00000000005ec6bd in Ffuncall (nargs=3, args=0x7ffd186d3050) at eval.c:2614
fun = 12488173
original_fun = 23712
funcar = 4
numargs = 2
lisp_numargs = 0
val = 0
internal_args = 0x5ec1b4d
count = 4
#30 0x00000000005e6d88 in Fcall_interactively (function=531888, record_flag=0,
keys=99359565) at callint.c:838
val = 6216502
args = 0x7ffd186d3050
visargs = 0x7ffd186d3068
specs = 63295988
filter_specs = 63295988
teml = 5550624
up_event = 0
enable = 0
sa_avail = 16310
sa_count = 4
sa_must_free = false
speccount = 4
next_event = 1
prefix_arg = 0
string = 0x7ffd186d30b0 "e"
tem = 0x6b5e64 ""
varies = 0x7ffd186d3080 ""
i = 3
nargs = 3
mark = 0
arg_from_tty = false
key_count = 1
record_then_fail = false
save_this_command = 0
save_last_command = 3683120
save_this_original_command = 0
save_real_this_command = 0
#31 0x00000000005ec82a in Ffuncall (nargs=4, args=0x7ffd186d3378) at eval.c:2641
internal_argbuf = {531888, 0, 13033552, 6092864, 0, 140725013263072, 5546337,
16512}
fun = 12488221
original_fun = 374592
funcar = 13033552
numargs = 3
lisp_numargs = 13033552
val = 0
internal_args = 0x7ffd186d3380
count = 3
#32 0x000000000062f86b in exec_byte_code (bytestr=10351284, vector=10351317, maxdepth=54,
args_template=4102, nargs=4, args=0x7ffd186d38f8) at bytecode.c:880
targets = {0x632f6d <exec_byte_code+17119>, 0x632fcd <exec_byte_code+17215>,
0x632fcf <exec_byte_code+17217>, 0x632fd1 <exec_byte_code+17219>,
0x632fd3 <exec_byte_code+17221>, 0x632fd3 <exec_byte_code+17221>,
0x633033 <exec_byte_code+17317>, 0x6330a6 <exec_byte_code+17432>,
0x62f0f0 <exec_byte_code+1122>, 0x62f0f2 <exec_byte_code+1124>,
---Type <return> to continue, or q <return> to quit---
0x62f0f4 <exec_byte_code+1126>, 0x62f0f6 <exec_byte_code+1128>,
0x62f0f8 <exec_byte_code+1130>, 0x62f0f8 <exec_byte_code+1130>,
0x62f0fe <exec_byte_code+1136>, 0x62f0b3 <exec_byte_code+1061>,
0x62f575 <exec_byte_code+2279>, 0x62f577 <exec_byte_code+2281>,
0x62f579 <exec_byte_code+2283>, 0x62f57b <exec_byte_code+2285>,
0x62f57d <exec_byte_code+2287>, 0x62f57d <exec_byte_code+2287>,
0x62f5be <exec_byte_code+2352>, 0x62f583 <exec_byte_code+2293>,
0x62f776 <exec_byte_code+2792>, 0x62f778 <exec_byte_code+2794>,
0x62f77a <exec_byte_code+2796>, 0x62f77c <exec_byte_code+2798>,
0x62f77e <exec_byte_code+2800>, 0x62f77e <exec_byte_code+2800>,
0x62f71e <exec_byte_code+2704>, 0x62f73b <exec_byte_code+2733>,
0x62f838 <exec_byte_code+2986>, 0x62f83a <exec_byte_code+2988>,
0x62f83c <exec_byte_code+2990>, 0x62f83e <exec_byte_code+2992>,
0x62f840 <exec_byte_code+2994>, 0x62f840 <exec_byte_code+2994>,
0x62f7e0 <exec_byte_code+2898>, 0x62f7fd <exec_byte_code+2927>,
0x62f8fa <exec_byte_code+3180>, 0x62f8fc <exec_byte_code+3182>,
0x62f8fe <exec_byte_code+3184>, 0x62f900 <exec_byte_code+3186>,
0x62f902 <exec_byte_code+3188>, 0x62f902 <exec_byte_code+3188>,
0x62f8a2 <exec_byte_code+3092>, 0x62f8bf <exec_byte_code+3121>,
0x6309b7 <exec_byte_code+7465>, 0x63078c <exec_byte_code+6910>,
0x630783 <exec_byte_code+6901>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x630bdd <exec_byte_code+8015>, 0x630cb6 <exec_byte_code+8232>,
0x630d14 <exec_byte_code+8326>, 0x630d73 <exec_byte_code+8421>,
0x630dd6 <exec_byte_code+8520>, 0x62f3ef <exec_byte_code+1889>,
0x62f465 <exec_byte_code+2007>, 0x630e4b <exec_byte_code+8637>,
0x62f346 <exec_byte_code+1720>, 0x62f4cb <exec_byte_code+2109>,
0x630eb1 <exec_byte_code+8739>, 0x630f17 <exec_byte_code+8841>,
0x630f5d <exec_byte_code+8911>, 0x630fc3 <exec_byte_code+9013>,
0x631010 <exec_byte_code+9090>, 0x6310dd <exec_byte_code+9295>,
0x631123 <exec_byte_code+9365>, 0x631189 <exec_byte_code+9467>,
0x63120c <exec_byte_code+9598>, 0x631252 <exec_byte_code+9668>,
0x631298 <exec_byte_code+9738>, 0x6312fe <exec_byte_code+9840>,
0x631364 <exec_byte_code+9942>, 0x6313ca <exec_byte_code+10044>,
0x63144d <exec_byte_code+10175>, 0x63149a <exec_byte_code+10252>,
0x6314e7 <exec_byte_code+10329>, 0x6315b4 <exec_byte_code+10534>,
0x631645 <exec_byte_code+10679>, 0x6316d6 <exec_byte_code+10824>,
0x631927 <exec_byte_code+11417>, 0x631992 <exec_byte_code+11524>,
0x6319fd <exec_byte_code+11631>, 0x631a68 <exec_byte_code+11738>,
0x631ad3 <exec_byte_code+11845>, 0x631b20 <exec_byte_code+11922>,
0x631bb2 <exec_byte_code+12068>, 0x631bff <exec_byte_code+12145>,
0x631c4c <exec_byte_code+12222>, 0x631c99 <exec_byte_code+12299>,
0x631d99 <exec_byte_code+12555>, 0x630620 <exec_byte_code+6546>,
0x631df6 <exec_byte_code+12648>, 0x631e3c <exec_byte_code+12718>,
0x631f04 <exec_byte_code+12918>, 0x631f61 <exec_byte_code+13011>,
0x631fbe <exec_byte_code+13104>, 0x632004 <exec_byte_code+13174>,
0x632050 <exec_byte_code+13250>, 0x63209c <exec_byte_code+13326>,
0x6320f0 <exec_byte_code+13410>, 0x632f6d <exec_byte_code+17119>,
0x632146 <exec_byte_code+13496>, 0x632187 <exec_byte_code+13561>,
0x6321c8 <exec_byte_code+13626>, 0x632209 <exec_byte_code+13691>,
0x63224a <exec_byte_code+13756>, 0x63228b <exec_byte_code+13821>,
0x630620 <exec_byte_code+6546>, 0x632f6d <exec_byte_code+17119>,
0x6322d1 <exec_byte_code+13891>, 0x63231f <exec_byte_code+13969>,
0x632365 <exec_byte_code+14039>, 0x6323ab <exec_byte_code+14109>,
0x632411 <exec_byte_code+14211>, 0x632477 <exec_byte_code+14313>,
0x6324bd <exec_byte_code+14383>, 0x6325ad <exec_byte_code+14623>,
---Type <return> to continue, or q <return> to quit---
0x632613 <exec_byte_code+14725>, 0x632679 <exec_byte_code+14827>,
0x6326df <exec_byte_code+14929>, 0x632720 <exec_byte_code+14994>,
0x632f6d <exec_byte_code+17119>, 0x630557 <exec_byte_code+6345>,
0x62f9a7 <exec_byte_code+3353>, 0x62f1e6 <exec_byte_code+1368>,
0x62fada <exec_byte_code+3660>, 0x62fc3a <exec_byte_code+4012>,
0x62fd8e <exec_byte_code+4352>, 0x6304e8 <exec_byte_code+6234>,
0x630525 <exec_byte_code+6295>, 0x62f6d0 <exec_byte_code+2626>,
0x6305e1 <exec_byte_code+6483>, 0x630652 <exec_byte_code+6596>,
0x6306dc <exec_byte_code+6734>, 0x63071b <exec_byte_code+6797>,
0x6309f6 <exec_byte_code+7528>, 0x630a78 <exec_byte_code+7658>,
0x630afb <exec_byte_code+7789>, 0x630b5c <exec_byte_code+7886>,
0x62f95e <exec_byte_code+3280>, 0x632766 <exec_byte_code+15064>,
0x6327e9 <exec_byte_code+15195>, 0x63282f <exec_byte_code+15265>,
0x632875 <exec_byte_code+15335>, 0x6328bb <exec_byte_code+15405>,
0x632901 <exec_byte_code+15475>, 0x632967 <exec_byte_code+15577>,
0x6329cd <exec_byte_code+15679>, 0x632a33 <exec_byte_code+15781>,
0x632a99 <exec_byte_code+15883>, 0x632bd8 <exec_byte_code+16202>,
0x632c3e <exec_byte_code+16304>, 0x632ca4 <exec_byte_code+16406>,
0x632cea <exec_byte_code+16476>, 0x632d50 <exec_byte_code+16578>,
0x632db6 <exec_byte_code+16680>, 0x632e0a <exec_byte_code+16764>,
0x632e5e <exec_byte_code+16848>, 0x631ce6 <exec_byte_code+12376>,
0x631d33 <exec_byte_code+12453>, 0x632eab <exec_byte_code+16925>,
0x632f0e <exec_byte_code+17024>, 0x632f6d <exec_byte_code+17119>,
0x62fee2 <exec_byte_code+4692>, 0x62ffe8 <exec_byte_code+4954>,
0x63012d <exec_byte_code+5279>, 0x630272 <exec_byte_code+5604>,
0x6303ad <exec_byte_code+5919>, 0x63105d <exec_byte_code+9167>,
0x631534 <exec_byte_code+10406>, 0x631e84 <exec_byte_code+12790>,
0x633140 <exec_byte_code+17586>, 0x6331b6 <exec_byte_code+17704>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x633253 <exec_byte_code+17861>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x632f6d <exec_byte_code+17119>, 0x632f6d <exec_byte_code+17119>,
0x6332db <exec_byte_code+17997> <repeats 64 times>}
count = 3
op = 3
vectorp = 0x9df2d8 <pure+889496>
stack = {
pc = 0xb94e83 <pure+2682435> "\006\006\071\203\242",
byte_string = 10351284,
byte_string_start = 0xb94e08 <pure+2682312> "\306\020\211?\205\023",
next = 0x0
}
top = 0x7ffd186d3378
result = 140725013264640
type = (CONDITION_CASE | unknown: 32764)
#33 0x00000000005ecfc1 in funcall_lambda (fun=10351237, nargs=4, arg_vector=0x7ffd186d38d8)
at eval.c:2794
val = 4
syms_left = 4102
next = 13033552
lexenv = 51949418432
count = 3
i = 5550624
optional = false
rest = false
---Type <return> to continue, or q <return> to quit---
#34 0x00000000005eca3e in Ffuncall (nargs=5, args=0x7ffd186d38d0) at eval.c:2683
fun = 10351237
original_fun = 14736
funcar = 13297187
numargs = 4
lisp_numargs = 21312
val = 21488333955
internal_args = 0x5c6787 <allocate_vector+79>
count = 2
#35 0x00000000005ec2c6 in call4 (fn=14736, arg1=531888, arg2=0, arg3=99359565, arg4=43968)
at eval.c:2518
No locals.
#36 0x00000000005560b2 in read_char (commandflag=1, map=99961251, prev_event=0,
used_mouse_menu=0x7ffd186d3c6f, end_time=0x0) at keyboard.c:2831
prev_buffer = 0x5f4e500
c = 100156099
jmpcount = 2
local_getcjmp = {{
__jmpbuf = {0, 7193965397756376897, 4290448, 140725013267104, 0, 0,
7193965397590701889, -7193329316773464255},
__mask_was_saved = 0,
__saved_mask = {
__val = {16675888, 13033552, 6091557, 0, 140725013265072, 5546337, 18200768,
13033552, 5679054, 0, 140725013265120, 5546337, 99961235, 140725013265216,
6216502, 0}
}
}}
save_jump = {{
__jmpbuf = {0, 7193965398937073473, 43968, 38, 0, 0, 7193965398771398465,
-7193329316773464255},
__mask_was_saved = 0,
__saved_mask = {
__val = {4301116442, 73668401, 0, 72057594050961488, 3835, 3835, 73664600,
0, 140725013241760, 43968, 0, 5546337, 3835, 3835, 12860880, 0}
}
}}
tem = 531888
save = 0
previous_echo_area_message = 0
also_record = 0
reread = false
recorded = false
polling_stopped_here = false
orig_kboard = 0x1c24570
#37 0x00000000005625d1 in read_key_sequence (keybuf=0x7ffd186d3e20, bufsize=30, prompt=0,
dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true,
prevent_redisplay=false) at keyboard.c:9030
interrupted_kboard = 0x1c24570
interrupted_frame = 0x129eca0
key = 27120
used_mouse_menu = false
echo_local_start = 0
last_real_key_start = 0
keys_local_start = 0
new_binding = 140725013265888
count = 2
t = 0
---Type <return> to continue, or q <return> to quit---
echo_start = 0
keys_start = 0
current_binding = 99961251
first_event = 0
first_unbound = 31
mock_input = 0
fkey = {
parent = 17003475,
map = 17003475,
start = 0,
end = 0
}
keytran = {
parent = 13297219,
map = 13297219,
start = 0,
end = 0
}
indec = {
parent = 17003619,
map = 17003619,
start = 0,
end = 0
}
shift_translated = false
delayed_switch_frame = 0
original_uppercase = 5546337
original_uppercase_position = -1
dummyflag = false
starting_buffer = 0x5f4e500
fake_prefixed_keys = 0
#38 0x0000000000552a3c in command_loop_1 () at keyboard.c:1348
cmd = 3683072
keybuf = {46, 110, 110, 9461860, 322320, 2, 3, 140725013266104, 0, 9449461,
140725013266096, 0, 140725013266128, 6210159, 0, 9461860, 13033552, 322320, 0,
140725013266128, 5546337, 0, 13033552, 5578885, 0, 140725013266176, 5546337, 2,
140725013266288, 5578688}
i = 1
prev_modiff = 608
prev_buffer = 0x5f4e500
already_adjusted = false
#39 0x00000000005e9590 in internal_condition_case (bfun=0x552632 <command_loop_1>,
handlers=18912, hfun=0x551e1c <cmd_error>) at eval.c:1293
val = 5546337
c = 0x14e7da0
#40 0x0000000000552339 in command_loop_2 (ignore=0) at keyboard.c:1088
val = 2
#41 0x00000000005e8d52 in internal_catch (tag=45312, func=0x552310 <command_loop_2>, arg=0)
at eval.c:1057
val = 5546337
c = 0x14e7c70
#42 0x00000000005522db in command_loop () at keyboard.c:1067
No locals.
#43 0x00000000005519e4 in recursive_edit_1 () at keyboard.c:673
count = 1
val = 140725013266592
#44 0x0000000000551b78 in Frecursive_edit () at keyboard.c:744
---Type <return> to continue, or q <return> to quit---
count = 0
buffer = 0
#45 0x000000000054fa73 in main (argc=1, argv=0x7ffd186d42a8) at emacs.c:1643
dummy = 0
stack_bottom_variable = 0 '\000'
do_initial_setlocale = true
dumping = false
skip_args = 0
rlim = {
rlim_cur = 8720000,
rlim_max = 18446744073709551615
}
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = 0x0
Lisp Backtrace:
"Automatic GC" (0x0)
"aggressive-indent--keep-track-of-changes" (0x186d1a48)
"backtrace" (0x186d1c48)
"debugger-setup-buffer" (0x186d2260)
"debug" (0x186d27a8)
"signal" (0x186d2a68)
"file-notify-handle-event" (0x186d3060)
"funcall-interactively" (0x186d3058)
"call-interactively" (0x186d3380)
"command-execute" (0x186d38d8)
(gdb)
--8<---------------cut here---------------end--------------->8---
Bye,
Tassilo
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-09-11 12:28 ` Tassilo Horn
@ 2015-09-11 12:39 ` Eli Zaretskii
2015-09-11 13:06 ` Tassilo Horn
0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2015-09-11 12:39 UTC (permalink / raw)
To: Tassilo Horn; +Cc: 21313
> From: Tassilo Horn <tsdh@gnu.org>
> Date: Fri, 11 Sep 2015 14:28:51 +0200
>
> Just now, I had three other strange errors during killing in
> message-mode. The first two were about errors in
> `file-notify-handle-event' which was called with something wrong. With
> the first error, it received a buffer (!) instead of an event, with the
> second error I think it received something else which I can't remember.
> At least it hasn't been a file-notification event.
I think this is the same problem as the one fixed in bug #21337,
except that the cause for the problem is different: where it was
GnuTLS in that bug, it's something else in yours.
So I suggest to read the description of the root cause posted by
Robert Pluim in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21337#31,
and then look for something very similar, but involving other sources
of input events, perhaps D-Bus. The symptoms you describe exactly
match what he explained there.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-09-11 12:39 ` Eli Zaretskii
@ 2015-09-11 13:06 ` Tassilo Horn
2015-09-11 13:59 ` Eli Zaretskii
0 siblings, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-09-11 13:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 21313
Eli Zaretskii <eliz@gnu.org> writes:
>> Just now, I had three other strange errors during killing in
>> message-mode. The first two were about errors in
>> `file-notify-handle-event' which was called with something wrong.
>> With the first error, it received a buffer (!) instead of an event,
>> with the second error I think it received something else which I
>> can't remember. At least it hasn't been a file-notification event.
>
> I think this is the same problem as the one fixed in bug #21337,
> except that the cause for the problem is different: where it was
> GnuTLS in that bug, it's something else in yours.
Yes, seems so.
> So I suggest to read the description of the root cause posted by
> Robert Pluim in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21337#31,
> and then look for something very similar, but involving other sources
> of input events, perhaps D-Bus. The symptoms you describe exactly
> match what he explained there.
The problem is that I have almost no idea what that code does and how it
is intended to work, so I can't really debug it in a sensible way.
And to make things worse, I think this issue also has some timing
component in it. That is, it only happens when I press and hold C-k for
at least one or two seconds which kills quite a lot of lines given that
I use a very fast keyboard repeat rate. When I kill just the lines of a
paragraph like this one, then take a short pause, then kill the next
one, the issue is much less likely to appear. So emacs needs to be
flooded with events in some sense.
If you have some ideas where things could go wrong, I'm happy to do
whatever may help. Maybe adding some debugging code or conditional
breakpoints could narrow down the scope a bit?
BTW, the last errors came from `file-notify-handle-event' but I'm
reasonably sure that in this emacs session I only had used Gnus so far.
I don't use auto-revert-mode, so actually filenotify.el should not even
have been loaded so far and no watches should have existed. My current
emacs session is the same: only Gnus => (featurep 'filenotify) ;=> nil.
Does that give any clue?
Bye,
Tassilo
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-09-11 13:06 ` Tassilo Horn
@ 2015-09-11 13:59 ` Eli Zaretskii
2015-09-15 15:37 ` Tassilo Horn
0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2015-09-11 13:59 UTC (permalink / raw)
To: Tassilo Horn; +Cc: 21313
> From: Tassilo Horn <tsdh@gnu.org>
> Cc: 21313@debbugs.gnu.org
> Date: Fri, 11 Sep 2015 15:06:48 +0200
>
> > So I suggest to read the description of the root cause posted by
> > Robert Pluim in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21337#31,
> > and then look for something very similar, but involving other sources
> > of input events, perhaps D-Bus. The symptoms you describe exactly
> > match what he explained there.
>
> The problem is that I have almost no idea what that code does and how it
> is intended to work, so I can't really debug it in a sensible way.
You mean, wait_reading_process_output? Please feel free to ask
questions about the things you don't understand.
In a nutshell, it waits until one of the input sources has some input,
and then we read from that source using whatever method is appropriate
for interpreting that source.
> If you have some ideas where things could go wrong, I'm happy to do
> whatever may help.
I think things go wrong exactly like in that other bug: we have some
source ready to be read from, but dispatch those events to a "handler"
for another source.
> Maybe adding some debugging code or conditional breakpoints could
> narrow down the scope a bit?
I'd start by looking at the indicators returned by 'pselect'.
> BTW, the last errors came from `file-notify-handle-event' but I'm
> reasonably sure that in this emacs session I only had used Gnus so far.
> I don't use auto-revert-mode, so actually filenotify.el should not even
> have been loaded so far and no watches should have existed. My current
> emacs session is the same: only Gnus => (featurep 'filenotify) ;=> nil.
> Does that give any clue?
My theory is that we think there's an inotify event waiting to be
read, where in fact the event is of another kind, perhaps from D-Bus.
The flags returned by 'pselect' should tell you.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-09-11 13:59 ` Eli Zaretskii
@ 2015-09-15 15:37 ` Tassilo Horn
2015-09-15 16:01 ` Eli Zaretskii
0 siblings, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-09-15 15:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 21313
Eli Zaretskii <eliz@gnu.org> writes:
> You mean, wait_reading_process_output? Please feel free to ask
> questions about the things you don't understand.
>
> In a nutshell, it waits until one of the input sources has some input,
> and then we read from that source using whatever method is appropriate
> for interpreting that source.
As far as I understand, the file descriptors with pending input are
collected in the fd_set Available, and then this loop gives, e.g., dbus
and inotify handlers a chance to read input from the file descriptors
and convert it to events.
for (channel = 0; channel <= max_input_desc; ++channel)
{
struct fd_callback_data *d = &fd_callback_info[channel];
if (d->func
&& ((d->condition & FOR_READ
&& FD_ISSET (channel, &Available))
|| (d->condition & FOR_WRITE
&& FD_ISSET (channel, &write_mask))))
d->func (channel, d->data);
}
I wondered why channel is not removed from Available here. I mean,
input was available, and then the handlers registered using add_read_fd
by inotify or dbus consumed the input, so there's probably no input
left. So I tried this patch
--8<---------------cut here---------------start------------->8---
diff --git a/src/process.c b/src/process.c
index ed5f4c0..7985e37 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5036,7 +5036,10 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
&& FD_ISSET (channel, &Available))
|| (d->condition & FOR_WRITE
&& FD_ISSET (channel, &write_mask))))
- d->func (channel, d->data);
+ {
+ d->func (channel, d->data);
+ FD_CLR (channel, &Available);
+ }
}
for (channel = 0; channel <= max_process_desc; channel++)
--8<---------------cut here---------------end--------------->8---
and since then the problem has not appeared again and I can't see any
obvious other malfunction. But of course that's really a naive change.
I can grasp the big picture of wait_reading_process_output but not all
the details.
Bye,
Tassilo
^ permalink raw reply related [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
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
0 siblings, 2 replies; 44+ messages in thread
From: Eli Zaretskii @ 2015-09-15 16:01 UTC (permalink / raw)
To: Tassilo Horn; +Cc: 21313
> From: Tassilo Horn <tsdh@gnu.org>
> Cc: 21313@debbugs.gnu.org
> Date: Tue, 15 Sep 2015 17:37:02 +0200
>
> I wondered why channel is not removed from Available here. I mean,
> input was available, and then the handlers registered using add_read_fd
> by inotify or dbus consumed the input, so there's probably no input
> left. So I tried this patch
>
> --8<---------------cut here---------------start------------->8---
> diff --git a/src/process.c b/src/process.c
> index ed5f4c0..7985e37 100644
> --- a/src/process.c
> +++ b/src/process.c
> @@ -5036,7 +5036,10 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
> && FD_ISSET (channel, &Available))
> || (d->condition & FOR_WRITE
> && FD_ISSET (channel, &write_mask))))
> - d->func (channel, d->data);
> + {
> + d->func (channel, d->data);
> + FD_CLR (channel, &Available);
> + }
> }
>
> for (channel = 0; channel <= max_process_desc; channel++)
> --8<---------------cut here---------------end--------------->8---
>
> and since then the problem has not appeared again and I can't see any
> obvious other malfunction. But of course that's really a naive change.
> I can grasp the big picture of wait_reading_process_output but not all
> the details.
If no one objects in a week, please push this, and let's see what it
breaks.
Thanks.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-09-15 16:01 ` Eli Zaretskii
@ 2015-09-16 11:39 ` Tassilo Horn
2015-09-22 5:49 ` Tassilo Horn
1 sibling, 0 replies; 44+ messages in thread
From: Tassilo Horn @ 2015-09-16 11:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Jan Djärv, 21313
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Tassilo Horn <tsdh@gnu.org>
>> Cc: 21313@debbugs.gnu.org
>> Date: Tue, 15 Sep 2015 17:37:02 +0200
>>
>> I wondered why channel is not removed from Available here. I mean,
>> input was available, and then the handlers registered using add_read_fd
>> by inotify or dbus consumed the input, so there's probably no input
>> left. So I tried this patch
>>
>> --8<---------------cut here---------------start------------->8---
>> diff --git a/src/process.c b/src/process.c
>> index ed5f4c0..7985e37 100644
>> --- a/src/process.c
>> +++ b/src/process.c
>> @@ -5036,7 +5036,10 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
>> && FD_ISSET (channel, &Available))
>> || (d->condition & FOR_WRITE
>> && FD_ISSET (channel, &write_mask))))
>> - d->func (channel, d->data);
>> + {
>> + d->func (channel, d->data);
>> + FD_CLR (channel, &Available);
>> + }
>> }
>>
>> for (channel = 0; channel <= max_process_desc; channel++)
>> --8<---------------cut here---------------end--------------->8---
>>
>> and since then the problem has not appeared again and I can't see any
>> obvious other malfunction. But of course that's really a naive change.
>> I can grasp the big picture of wait_reading_process_output but not all
>> the details.
>
> If no one objects in a week, please push this, and let's see what it
> breaks.
Yes, I'll do. And I'v Cc-ed Jan in this mail because he's the original
author of that code and probably knows best if that's the right thing to
do.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
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
1 sibling, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-09-22 5:49 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 21313-done
Eli Zaretskii <eliz@gnu.org> writes:
>> I wondered why channel is not removed from Available here. I mean,
>> input was available, and then the handlers registered using
>> add_read_fd by inotify or dbus consumed the input, so there's
>> probably no input left. So I tried this patch
>>
>> --8<---------------cut here---------------start------------->8---
>> diff --git a/src/process.c b/src/process.c
>> index ed5f4c0..7985e37 100644
>> --- a/src/process.c
>> +++ b/src/process.c
>> @@ -5036,7 +5036,10 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
>> && FD_ISSET (channel, &Available))
>> || (d->condition & FOR_WRITE
>> && FD_ISSET (channel, &write_mask))))
>> - d->func (channel, d->data);
>> + {
>> + d->func (channel, d->data);
>> + FD_CLR (channel, &Available);
>> + }
>> }
>>
>> for (channel = 0; channel <= max_process_desc; channel++)
>> --8<---------------cut here---------------end--------------->8---
>>
>> and since then the problem has not appeared again and I can't see any
>> obvious other malfunction. But of course that's really a naive
>> change. I can grasp the big picture of wait_reading_process_output
>> but not all the details.
>
> If no one objects in a week, please push this, and let's see what it
> breaks.
I've run with this patch for about a week now and the issue hasn't
occurred anymore. So I just pushed it and close the bug report with
this mail.
Thanks for your assistance!
Bye,
Tassilo
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-09-22 5:49 ` Tassilo Horn
@ 2015-09-22 8:00 ` Robert Pluim
2015-09-22 8:21 ` Tassilo Horn
0 siblings, 1 reply; 44+ messages in thread
From: Robert Pluim @ 2015-09-22 8:00 UTC (permalink / raw)
To: 21313; +Cc: tsdh
Tassilo Horn <tsdh@gnu.org> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> I wondered why channel is not removed from Available here. I mean,
>>> input was available, and then the handlers registered using
>>> add_read_fd by inotify or dbus consumed the input, so there's
>>> probably no input left. So I tried this patch
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> diff --git a/src/process.c b/src/process.c
>>> index ed5f4c0..7985e37 100644
>>> --- a/src/process.c
>>> +++ b/src/process.c
>>> @@ -5036,7 +5036,10 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
>>> && FD_ISSET (channel, &Available))
>>> || (d->condition & FOR_WRITE
>>> && FD_ISSET (channel, &write_mask))))
>>> - d->func (channel, d->data);
>>> + {
>>> + d->func (channel, d->data);
>>> + FD_CLR (channel, &Available);
>>> + }
>>> }
>>>
>>> for (channel = 0; channel <= max_process_desc; channel++)
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> and since then the problem has not appeared again and I can't see any
>>> obvious other malfunction. But of course that's really a naive
>>> change. I can grasp the big picture of wait_reading_process_output
>>> but not all the details.
>>
>> If no one objects in a week, please push this, and let's see what it
>> breaks.
>
> I've run with this patch for about a week now and the issue hasn't
> occurred anymore. So I just pushed it and close the bug report with
> this mail.
What if it was the 'FOR_WRITE' part of the condition that triggered?
Perhaps we should split the 'if'.
Regards
Robert
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-09-22 8:00 ` Robert Pluim
@ 2015-09-22 8:21 ` Tassilo Horn
2015-10-02 18:36 ` Tassilo Horn
0 siblings, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-09-22 8:21 UTC (permalink / raw)
To: Robert Pluim; +Cc: 21313
Robert Pluim <rpluim@gmail.com> writes:
>>>> --8<---------------cut here---------------start------------->8---
>>>> diff --git a/src/process.c b/src/process.c
>>>> index ed5f4c0..7985e37 100644
>>>> --- a/src/process.c
>>>> +++ b/src/process.c
>>>> @@ -5036,7 +5036,10 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
>>>> && FD_ISSET (channel, &Available))
>>>> || (d->condition & FOR_WRITE
>>>> && FD_ISSET (channel, &write_mask))))
>>>> - d->func (channel, d->data);
>>>> + {
>>>> + d->func (channel, d->data);
>>>> + FD_CLR (channel, &Available);
>>>> + }
>>>> }
>>>>
>>>> for (channel = 0; channel <= max_process_desc; channel++)
>>>> --8<---------------cut here---------------end--------------->8---
>
> What if it was the 'FOR_WRITE' part of the condition that triggered?
> Perhaps we should split the 'if'.
I think in this case, channel cannot be in Available so by handling this
case we could only save one needless operation. But that might be
reason enough, so I committed the following patch.
--8<---------------cut here---------------start------------->8---
1 file changed, 10 insertions(+), 7 deletions(-)
src/process.c | 17 ++++++++++-------
modified src/process.c
@@ -5031,14 +5031,17 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
for (channel = 0; channel <= max_input_desc; ++channel)
{
struct fd_callback_data *d = &fd_callback_info[channel];
- if (d->func
- && ((d->condition & FOR_READ
- && FD_ISSET (channel, &Available))
- || (d->condition & FOR_WRITE
- && FD_ISSET (channel, &write_mask))))
+ if (d->func)
{
- d->func (channel, d->data);
- FD_CLR (channel, &Available);
+ if (d->condition & FOR_READ
+ && FD_ISSET (channel, &Available))
+ {
+ d->func (channel, d->data);
+ FD_CLR (channel, &Available);
+ }
+ else if (d->condition & FOR_WRITE
+ && FD_ISSET (channel, &write_mask))
+ d->func (channel, d->data);
}
}
--8<---------------cut here---------------end--------------->8---
Bye,
Tassilo
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-09-22 8:21 ` Tassilo Horn
@ 2015-10-02 18:36 ` Tassilo Horn
2015-10-02 19:05 ` Eli Zaretskii
0 siblings, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-10-02 18:36 UTC (permalink / raw)
To: Robert Pluim, Eli Zaretskii; +Cc: 21313
Hi guys,
apparently my commits
bfa1aa8 * Improve last commit to process.c
27f8719 * Remove callback-handled channels from Available set
didn't really fix this problem. I still occasionally get those strange
errors, e.g.,
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)
just now when killing text in a message-mode buffer. And I also had
some crashes again.
Should I revert these two commits?
Bye,
Tassilo
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-02 18:36 ` Tassilo Horn
@ 2015-10-02 19:05 ` Eli Zaretskii
2015-10-02 20:33 ` Tassilo Horn
0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2015-10-02 19:05 UTC (permalink / raw)
To: Tassilo Horn; +Cc: rpluim, 21313
> From: Tassilo Horn <tsdh@gnu.org>
> Cc: 21313@debbugs.gnu.org
> Date: Fri, 02 Oct 2015 20:36:18 +0200
>
> apparently my commits
>
> bfa1aa8 * Improve last commit to process.c
> 27f8719 * Remove callback-handled channels from Available set
>
> didn't really fix this problem. I still occasionally get those strange
> errors, e.g.,
>
> 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)
>
> just now when killing text in a message-mode buffer. And I also had
> some crashes again.
>
> 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, just
to continue investigating the problem.
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.
Thanks.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-02 19:05 ` Eli Zaretskii
@ 2015-10-02 20:33 ` Tassilo Horn
2015-10-02 21:10 ` Eli Zaretskii
0 siblings, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-10-02 20:33 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rpluim, 21313
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-02 20:33 ` Tassilo Horn
@ 2015-10-02 21:10 ` Eli Zaretskii
2015-10-02 21:26 ` Michael Albinus
0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2015-10-02 21:10 UTC (permalink / raw)
To: Tassilo Horn; +Cc: rpluim, 21313
> 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.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-02 21:10 ` Eli Zaretskii
@ 2015-10-02 21:26 ` Michael Albinus
2015-10-03 5:40 ` Tassilo Horn
0 siblings, 1 reply; 44+ messages in thread
From: Michael Albinus @ 2015-10-02 21:26 UTC (permalink / raw)
To: Tassilo Horn; +Cc: rpluim, 21313
Eli Zaretskii <eliz@gnu.org> writes:
>> 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.
> 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.
Well ... starting next Monday, I'm offline for about a week.
Best regards, Michael.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
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:43 ` Michael Albinus
0 siblings, 2 replies; 44+ messages in thread
From: Tassilo Horn @ 2015-10-03 5:40 UTC (permalink / raw)
To: Michael Albinus; +Cc: rpluim, 21313
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
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-03 5:40 ` Tassilo Horn
@ 2015-10-03 6:32 ` Tassilo Horn
2015-10-03 7:14 ` Eli Zaretskii
2015-10-03 7:43 ` Michael Albinus
1 sibling, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-10-03 6:32 UTC (permalink / raw)
To: Michael Albinus; +Cc: rpluim, 21313
Tassilo Horn <tsdh@gnu.org> writes:
> 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.
Can someone give me a hint what I'm doing wrong? With the changes below
keyboard.c still compiles but the step
./temacs --batch --load loadup bootstrap
starts using up all my RAM and swap space until I kill it.
--8<---------------cut here---------------start------------->8---
modified src/keyboard.c
@@ -3412,6 +3412,11 @@ kbd_buffer_nr_stored (void)
void
kbd_buffer_store_event (register struct input_event *event)
{
+ Faset (Vth_event_buffer, Vth_event_buffer_idx, make_lispy_event (event));
+ if (Vth_event_buffer_idx == 99)
+ Vth_event_buffer_idx = 0;
+ else
+ Vth_event_buffer_idx++;
kbd_buffer_store_event_hold (event, 0);
}
@@ -11131,6 +11136,14 @@ syms_of_keyboard (void)
defsubr (&Sposn_at_point);
defsubr (&Sposn_at_x_y);
+ DEFVAR_LISP ("th-input-event-buffer", Vth_event_buffer,
+ doc: /* The last 100 events. */);
+ Vth_event_buffer = Fmake_vector(100, 0);
+
+ DEFVAR_LISP ("th-input-event-buffer-idx", Vth_event_buffer_idx,
+ doc: /* Current index in th-event-buffer. */);
+ Vth_event_buffer_idx = 0;
+
DEFVAR_LISP ("last-command-event", last_command_event,
doc: /* Last input event that was part of a command. */);
--8<---------------cut here---------------end--------------->8---
Bye,
Tassilo
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-03 6:32 ` Tassilo Horn
@ 2015-10-03 7:14 ` Eli Zaretskii
2015-10-03 8:10 ` Tassilo Horn
0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2015-10-03 7:14 UTC (permalink / raw)
To: Tassilo Horn; +Cc: rpluim, michael.albinus, 21313
> From: Tassilo Horn <tsdh@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, rpluim@gmail.com, 21313@debbugs.gnu.org
> Date: Sat, 03 Oct 2015 08:32:56 +0200
>
> Can someone give me a hint what I'm doing wrong? With the changes below
> keyboard.c still compiles but the step
>
> ./temacs --batch --load loadup bootstrap
>
> starts using up all my RAM and swap space until I kill it.
>
> --8<---------------cut here---------------start------------->8---
> modified src/keyboard.c
> @@ -3412,6 +3412,11 @@ kbd_buffer_nr_stored (void)
> void
> kbd_buffer_store_event (register struct input_event *event)
> {
> + Faset (Vth_event_buffer, Vth_event_buffer_idx, make_lispy_event (event));
> + if (Vth_event_buffer_idx == 99)
> + Vth_event_buffer_idx = 0;
> + else
> + Vth_event_buffer_idx++;
> kbd_buffer_store_event_hold (event, 0);
> }
>
> @@ -11131,6 +11136,14 @@ syms_of_keyboard (void)
> defsubr (&Sposn_at_point);
> defsubr (&Sposn_at_x_y);
>
> + DEFVAR_LISP ("th-input-event-buffer", Vth_event_buffer,
> + doc: /* The last 100 events. */);
> + Vth_event_buffer = Fmake_vector(100, 0);
Fmake_vector needs a Lisp integer as its first argument, i.e. you need
to use make_number. (And I'd suggest to use Qnil or some other Lisp
object as the second, not a C zero, although currently Qnil's value is
indeed zero.)
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-03 5:40 ` Tassilo Horn
2015-10-03 6:32 ` Tassilo Horn
@ 2015-10-03 7:43 ` Michael Albinus
2015-10-03 8:13 ` Tassilo Horn
1 sibling, 1 reply; 44+ messages in thread
From: Michael Albinus @ 2015-10-03 7:43 UTC (permalink / raw)
To: Tassilo Horn; +Cc: rpluim, 21313
Tassilo Horn <tsdh@gnu.org> writes:
>> 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.
`unread-command-events' comes to mind. It is used to push events back
which have been read, but which shall be handled later. Maybe something
is broken in that mechanism.
Commit 5022e27dac4c13651941e425dbec5b3a2cecdae4 has made heavy changes
here. I do not say that it has broken things, but it was pushed about 2
weeks prior your bug report. Timing matters.
Maybe you can check whether the problem still happens with a checkout
dated before Aug 4th. I know, hard to reproduce ...
> Bye,
> Tassilo
Best regards, Michael.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-03 7:14 ` Eli Zaretskii
@ 2015-10-03 8:10 ` Tassilo Horn
2015-10-03 9:53 ` Eli Zaretskii
0 siblings, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-10-03 8:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rpluim, michael.albinus, 21313
Eli Zaretskii <eliz@gnu.org> writes:
> Fmake_vector needs a Lisp integer as its first argument, i.e. you need
> to use make_number. (And I'd suggest to use Qnil or some other Lisp
> object as the second, not a C zero, although currently Qnil's value is
> indeed zero.)
Ah, ok. And then Vth_event_buffer_idx also needs to be a Lisp integer.
So I tried this:
--8<---------------cut here---------------start------------->8---
diff --git a/src/keyboard.c b/src/keyboard.c
index 966af69..fce819c 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -3412,6 +3412,12 @@ kbd_buffer_nr_stored (void)
void
kbd_buffer_store_event (register struct input_event *event)
{
+ Faset (Vth_event_buffer, Vth_event_buffer_idx, make_lispy_event (event));
+ if (Vth_event_buffer_idx == make_number (99))
+ Vth_event_buffer_idx = make_number (0);
+ else
+ Vth_event_buffer_idx = call2 (Qplus, Vth_event_buffer, make_number (1));
+
kbd_buffer_store_event_hold (event, 0);
}
@@ -11131,6 +11137,14 @@ syms_of_keyboard (void)
defsubr (&Sposn_at_point);
defsubr (&Sposn_at_x_y);
+ DEFVAR_LISP ("th-input-event-buffer", Vth_event_buffer,
+ doc: /* The last 100 events. */);
+ Vth_event_buffer = Fmake_vector(make_number (100), Qnil);
+
+ DEFVAR_LISP ("th-input-event-buffer-idx", Vth_event_buffer_idx,
+ doc: /* Current index in th-event-buffer. */);
+ Vth_event_buffer_idx = make_number (0);
+
DEFVAR_LISP ("last-command-event", last_command_event,
doc: /* Last input event that was part of a command. */);
--8<---------------cut here---------------end--------------->8---
But then I get:
--8<---------------cut here---------------start------------->8---
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
make[2]: *** Waiting for unfinished jobs....
ELC pcmpl-linux.elc
In pcomplete/tar:
pcmpl-gnu.el:162:47:Warning: \u2018pcomplete-suffix-list\u2019 is an obsolete variable
(as of 24.1).
make[2]: Leaving directory '/home/horn/Repos/el/emacs-debug/lisp'
Makefile:292: recipe for target 'compile-main' failed
make[1]: *** [compile-main] Error 2
make[1]: Leaving directory '/home/horn/Repos/el/emacs-debug/lisp'
Makefile:385: recipe for target 'lisp' failed
make: *** [lisp] Error 2
--8<---------------cut here---------------end--------------->8---
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.
Well, I now try following Michaels suggesting of reverting this one
commit about `unread-command-events'.
Bye,
Tassilo
^ permalink raw reply related [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-03 7:43 ` Michael Albinus
@ 2015-10-03 8:13 ` Tassilo Horn
2015-10-03 9:38 ` Tassilo Horn
0 siblings, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-10-03 8:13 UTC (permalink / raw)
To: Michael Albinus; +Cc: rpluim, 21313
Michael Albinus <michael.albinus@gmx.de> writes:
>>> 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.
>
> `unread-command-events' comes to mind. It is used to push events back
> which have been read, but which shall be handled later. Maybe something
> is broken in that mechanism.
>
> Commit 5022e27dac4c13651941e425dbec5b3a2cecdae4 has made heavy changes
> here. I do not say that it has broken things, but it was pushed about 2
> weeks prior your bug report. Timing matters.
Indeed, the timing would be perfect. I'll try that out.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-03 8:13 ` Tassilo Horn
@ 2015-10-03 9:38 ` Tassilo Horn
2015-10-03 10:53 ` Eli Zaretskii
0 siblings, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-10-03 9:38 UTC (permalink / raw)
To: Michael Albinus; +Cc: 21313
Tassilo Horn <tsdh@gnu.org> writes:
>> Commit 5022e27dac4c13651941e425dbec5b3a2cecdae4 has made heavy
>> changes here. I do not say that it has broken things, but it was
>> pushed about 2 weeks prior your bug report. Timing matters.
>
> Indeed, the timing would be perfect. I'll try that out.
I'm now running with a local branch where that commit has been reverted.
No error until now but of course that has nothing to say. I'll just
keep using it for the next few weeks.
But looking at the changes of this commit, I think the functions it
touched are not used when editing in a message-mode buffer. At least I
get no trace output from tracing all functions reported by
git show 5022e27dac4c13651941e425dbec5b3a2cecdae4 | grep @@ \
| sed -e 's/@@.*@@ //' | sort | uniq
which obviously relies on the git diff hunk headers naming the right
functions but I think they do.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-03 8:10 ` Tassilo Horn
@ 2015-10-03 9:53 ` Eli Zaretskii
2015-10-03 12:06 ` Tassilo Horn
0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2015-10-03 9:53 UTC (permalink / raw)
To: Tassilo Horn; +Cc: rpluim, michael.albinus, 21313
> From: Tassilo Horn <tsdh@gnu.org>
> Cc: michael.albinus@gmx.de, rpluim@gmail.com, 21313@debbugs.gnu.org
> 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.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-03 9:38 ` Tassilo Horn
@ 2015-10-03 10:53 ` Eli Zaretskii
2015-10-14 9:58 ` Tassilo Horn
0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2015-10-03 10:53 UTC (permalink / raw)
To: Tassilo Horn; +Cc: michael.albinus, 21313
> From: Tassilo Horn <tsdh@gnu.org>
> Date: Sat, 03 Oct 2015 11:38:40 +0200
> Cc: 21313@debbugs.gnu.org
>
> But looking at the changes of this commit, I think the functions it
> touched are not used when editing in a message-mode buffer.
There's also 30a6b1f81412044aa7dda5573b0142a0a03c4fd3, although it was
supposed to deal only with recording input events for the purposes of
keyboard macros.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-03 9:53 ` Eli Zaretskii
@ 2015-10-03 12:06 ` Tassilo Horn
0 siblings, 0 replies; 44+ messages in thread
From: Tassilo Horn @ 2015-10-03 12:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rpluim, michael.albinus, 21313
Eli Zaretskii <eliz@gnu.org> writes:
>> 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.
Uh, well, does "by hand" mean reimplement make_lispy_event? I've tried
cheating and calling that on a copy of the actual input_event. At least
that compiles, emacs starts, and after some time my th-event-buffer will
have the number 7 at index 0, and eventually it'll segfault.
But I'm probably barking up the wrong tree anyway.
kbd_buffer_store_event doesn't seem to be called very frequently;
certainly not for every event.
--8<---------------cut here---------------start------------->8---
modified src/keyboard.c
@@ -3412,6 +3412,15 @@ kbd_buffer_nr_stored (void)
void
kbd_buffer_store_event (register struct input_event *event)
{
+ printf ("kbd_buffer_store_event: %d\n", event);
+ struct input_event event_copy = *event;
+ printf (" copy: %d\n", &event_copy);
+ Faset (Vth_event_buffer, Vth_event_buffer_idx, make_lispy_event (&event_copy));
+ if (Vth_event_buffer_idx == make_number (99))
+ Vth_event_buffer_idx = make_number (0);
+ else
+ Vth_event_buffer_idx = call2 (Qplus, Vth_event_buffer_idx, make_number (1));
+
kbd_buffer_store_event_hold (event, 0);
}
@@ -11131,6 +11140,14 @@ syms_of_keyboard (void)
defsubr (&Sposn_at_point);
defsubr (&Sposn_at_x_y);
+ DEFVAR_LISP ("th-input-event-buffer", Vth_event_buffer,
+ doc: /* The last 100 events. */);
+ Vth_event_buffer = Fmake_vector(make_number (100), Qnil);
+
+ DEFVAR_LISP ("th-input-event-buffer-idx", Vth_event_buffer_idx,
+ doc: /* Current index in th-event-buffer. */);
+ Vth_event_buffer_idx = make_number (0);
+
DEFVAR_LISP ("last-command-event", last_command_event,
doc: /* Last input event that was part of a command. */);
--8<---------------cut here---------------end--------------->8---
>> 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.
Yeah, that commit seems to be unrelated anyway.
> > But looking at the changes of this commit, I think the functions it
> > touched are not used when editing in a message-mode buffer.
>
> There's also 30a6b1f81412044aa7dda5573b0142a0a03c4fd3, although it was
> supposed to deal only with recording input events for the purposes of
> keyboard macros.
Ok, I'm running with that being reverted now.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-03 10:53 ` Eli Zaretskii
@ 2015-10-14 9:58 ` Tassilo Horn
2015-10-14 17:05 ` Eli Zaretskii
0 siblings, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-10-14 9:58 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael.albinus, 21313
Eli Zaretskii <eliz@gnu.org> writes:
Hi Eli,
>> But looking at the changes of this commit, I think the functions it
>> touched are not used when editing in a message-mode buffer.
>
> There's also 30a6b1f81412044aa7dda5573b0142a0a03c4fd3, although it was
> supposed to deal only with recording input events for the purposes of
> keyboard macros.
I've been running with the latest master with that single commit
reverted for the past 10 days and never had this issue again. So I'm
tempted to say that this commit is most probably the culprit.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-14 9:58 ` Tassilo Horn
@ 2015-10-14 17:05 ` Eli Zaretskii
2015-10-14 19:37 ` Tassilo Horn
0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2015-10-14 17:05 UTC (permalink / raw)
To: Tassilo Horn; +Cc: michael.albinus, 21313
> From: Tassilo Horn <tsdh@gnu.org>
> Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org
> Date: Wed, 14 Oct 2015 11:58:35 +0200
>
> > There's also 30a6b1f81412044aa7dda5573b0142a0a03c4fd3, although it was
> > supposed to deal only with recording input events for the purposes of
> > keyboard macros.
>
> I've been running with the latest master with that single commit
> reverted for the past 10 days and never had this issue again. So I'm
> tempted to say that this commit is most probably the culprit.
The only effect of that change is to call record_char on some events
that might have evaded that before. record_char does 2 things:
. it adds the event to recent-keys, a Lisp array
. it records the event as part of a keyboard macro, if a macro is
being recorded
(There's also the "dribble" part, but I doubt that you are running
with that enabled.)
So I wonder how could any of that cause the kind of trouble you
reported.
If you undo the revert of that commit, do you start seeing the problem
again?
If you do, please see which of the "unusual" events, if any, get
passed to record_char, and whether they are recorded as part of
recent-keys and keyboard macros (assuming that you are used to define
and invoke macros in your routine work).
Thanks.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-14 17:05 ` Eli Zaretskii
@ 2015-10-14 19:37 ` Tassilo Horn
2015-10-14 19:43 ` Eli Zaretskii
0 siblings, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-10-14 19:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael.albinus, 21313
Eli Zaretskii <eliz@gnu.org> writes:
>> > There's also 30a6b1f81412044aa7dda5573b0142a0a03c4fd3, although it
>> > was supposed to deal only with recording input events for the
>> > purposes of keyboard macros.
>>
>> I've been running with the latest master with that single commit
>> reverted for the past 10 days and never had this issue again. So I'm
>> tempted to say that this commit is most probably the culprit.
>
> The only effect of that change is to call record_char on some events
> that might have evaded that before. record_char does 2 things:
>
> . it adds the event to recent-keys, a Lisp array
> . it records the event as part of a keyboard macro, if a macro is
> being recorded
>
> (There's also the "dribble" part, but I doubt that you are running
> with that enabled.)
No, I don't run that.
> So I wonder how could any of that cause the kind of trouble you
> reported.
Me, too.
> If you undo the revert of that commit, do you start seeing the problem
> again?
I'm back on master now so we'll see.
> If you do, please see which of the "unusual" events, if any, get
> passed to record_char, and whether they are recorded as part of
> recent-keys and keyboard macros
I added some debug code which spits out something like
record_char: 107
-> NOT storing as part of macro
-2> set to recent_keys at index 28
where the 107 is the result of formatting the Lisp_Object with "%S", the
second line indicates if store_kbd_macro_char is doing something, and
the -2> line means that the second ASET (recent_keys, ...) invocation in
record_char has been executed.
That's what you had in mind, right?
> (assuming that you are used to define and invoke macros in your
> routine work).
Yes, but not too frequently. Macros haven't been involved when I had
those issues unless it is possible that some macro recording/replaying
I've done much earlier could have had a side-effect which appears much
later when killing text in a message-mode buffer.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-14 19:37 ` Tassilo Horn
@ 2015-10-14 19:43 ` Eli Zaretskii
2015-10-15 11:37 ` Tassilo Horn
0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2015-10-14 19:43 UTC (permalink / raw)
To: Tassilo Horn; +Cc: michael.albinus, 21313
> From: Tassilo Horn <tsdh@gnu.org>
> Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org
> Date: Wed, 14 Oct 2015 21:37:17 +0200
>
> I'm back on master now so we'll see.
>
> > If you do, please see which of the "unusual" events, if any, get
> > passed to record_char, and whether they are recorded as part of
> > recent-keys and keyboard macros
>
> I added some debug code which spits out something like
>
> record_char: 107
> -> NOT storing as part of macro
> -2> set to recent_keys at index 28
>
> where the 107 is the result of formatting the Lisp_Object with "%S", the
> second line indicates if store_kbd_macro_char is doing something, and
> the -2> line means that the second ASET (recent_keys, ...) invocation in
> record_char has been executed.
>
> That's what you had in mind, right?
Yes, thanks.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-14 19:43 ` Eli Zaretskii
@ 2015-10-15 11:37 ` Tassilo Horn
2015-10-15 16:56 ` Eli Zaretskii
0 siblings, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-10-15 11:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael.albinus, 21313
Eli Zaretskii <eliz@gnu.org> writes:
>> I added some debug code which spits out something like
>>
>> record_char: 107
>> -> NOT storing as part of macro
>> -2> set to recent_keys at index 28
>>
>> where the 107 is the result of formatting the Lisp_Object with "%S", the
>> second line indicates if store_kbd_macro_char is doing something, and
>> the -2> line means that the second ASET (recent_keys, ...) invocation in
>> record_char has been executed.
>>
>> That's what you had in mind, right?
>
> Yes, thanks.
Ok, great. But somehow my debugging code changes the behavior with
respect to hitting C-g in the minibuffer and I don't see how that can
happen.
Concretely, normally C-g in the minibuffer will exit the minibuffer or
exit the recursive minibuffer popping to the previous one. But with my
change, I need to hit C-g twice in quick succession. A single C-g does
nothing (record_char isn't called at all), and pressing it many times
with reasonably long pauses in between does nothing, too (no
record_char).
Oh, wait. Now I can tell you exactly how quickly I have to type the
second C-g. When I type C-g, the echo area shows Quit and then switches
back to the prompt I had before. The second C-g must come within the
time the echo area still shows Quit.
That's the output I get when doing M-x C-g C-g quickly. The second
record_char output appears just after the second C-g in the sequence.
--8<---------------cut here---------------start------------->8---
record_char: 134217848 ;; M-x
-> NOT storing as part of macro
-2> set to recent_keys at index 15
record_char: 7 ;; issued after C-g twice in quick succession
-> NOT storing as part of macro
-2> set to recent_keys at index 17
--8<---------------cut here---------------end--------------->8---
And these are my changes. Do you see anything stupid in there, or is
this some sort of a timing issue (which would at least partially explain
why I seem to be the only one seeing these "strange problems")?
--8<---------------cut here---------------start------------->8---
debug-record_char 74795245e4afc71dac56cd625a574a13be42227e
Author: Tassilo Horn <tsdh@gnu.org>
AuthorDate: Wed Oct 14 21:22:27 2015 +0200
Commit: Tassilo Horn <tsdh@gnu.org>
CommitDate: Thu Oct 15 13:29:28 2015 +0200
Parent: 59def59 Refer to `(elisp)Basic Completion' in completing-read docstring
Merged: debug-record_char master
Containing: debug-record_char
Follows: emacs-24.5-rc3-fixed (6228)
Debug record_char
2 files changed, 11 insertions(+), 1 deletion(-)
src/keyboard.c | 8 ++++++++
src/macros.c | 4 +++-
modified src/keyboard.c
@@ -3151,6 +3151,9 @@ help_char_p (Lisp_Object c)
static void
record_char (Lisp_Object c)
{
+ AUTO_STRING (format, "%S");
+ printf ("record_char: %s\n", SSDATA (CALLN (Fformat, format, c)));
+
int recorded = 0;
if (CONSP (c) && (EQ (XCAR (c), Qhelp_echo) || EQ (XCAR (c), Qmouse_movement)))
@@ -3213,6 +3216,7 @@ record_char (Lisp_Object c)
{
ASET (recent_keys, ix1, c);
recorded = 1;
+ printf (" -1> set to recent_keys at index %d\n", ix1);
}
}
}
@@ -3223,6 +3227,7 @@ record_char (Lisp_Object c)
{
total_keys += total_keys < NUM_RECENT_KEYS;
ASET (recent_keys, recent_keys_index, c);
+ printf (" -2> set to recent_keys at index %d\n", recent_keys_index);
if (++recent_keys_index >= NUM_RECENT_KEYS)
recent_keys_index = 0;
}
@@ -3242,9 +3247,12 @@ record_char (Lisp_Object c)
if (--recent_keys_index < 0)
recent_keys_index = NUM_RECENT_KEYS - 1;
ASET (recent_keys, recent_keys_index, Qnil);
+ printf (" -3> set to recent_keys at index %d\n", recent_keys_index);
}
}
+ fflush (stdout);
+
num_nonmacro_input_events++;
/* Write c to the dribble file. If c is a lispy event, write
modified src/macros.c
@@ -185,6 +185,7 @@ store_kbd_macro_char (Lisp_Object c)
if (!NILP (KVAR (kb, defining_kbd_macro)))
{
+ printf (" -> storing as part of macro\n");
if (kb->kbd_macro_ptr - kb->kbd_macro_buffer == kb->kbd_macro_bufsize)
{
ptrdiff_t ptr_offset, end_offset, nbytes;
@@ -200,9 +201,10 @@ store_kbd_macro_char (Lisp_Object c)
kb->kbd_macro_ptr = kb->kbd_macro_buffer + ptr_offset;
kb->kbd_macro_end = kb->kbd_macro_buffer + end_offset;
}
-
*kb->kbd_macro_ptr++ = c;
}
+ else
+ printf (" -> NOT storing as part of macro\n");
}
/* Declare that all chars stored so far in the kbd macro being defined
--8<---------------cut here---------------end--------------->8---
Bye,
Tassilo
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-15 11:37 ` Tassilo Horn
@ 2015-10-15 16:56 ` Eli Zaretskii
2015-10-15 17:35 ` Tassilo Horn
0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2015-10-15 16:56 UTC (permalink / raw)
To: Tassilo Horn; +Cc: michael.albinus, 21313
> From: Tassilo Horn <tsdh@gnu.org>
> Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org
> Date: Thu, 15 Oct 2015 13:37:05 +0200
>
> Concretely, normally C-g in the minibuffer will exit the minibuffer or
> exit the recursive minibuffer popping to the previous one. But with my
> change, I need to hit C-g twice in quick succession. A single C-g does
> nothing (record_char isn't called at all), and pressing it many times
> with reasonably long pauses in between does nothing, too (no
> record_char).
>
> Oh, wait. Now I can tell you exactly how quickly I have to type the
> second C-g. When I type C-g, the echo area shows Quit and then switches
> back to the prompt I had before. The second C-g must come within the
> time the echo area still shows Quit.
>
> That's the output I get when doing M-x C-g C-g quickly. The second
> record_char output appears just after the second C-g in the sequence.
>
> --8<---------------cut here---------------start------------->8---
> record_char: 134217848 ;; M-x
> -> NOT storing as part of macro
> -2> set to recent_keys at index 15
> record_char: 7 ;; issued after C-g twice in quick succession
> -> NOT storing as part of macro
> -2> set to recent_keys at index 17
> --8<---------------cut here---------------end--------------->8---
>
> And these are my changes. Do you see anything stupid in there, or is
> this some sort of a timing issue (which would at least partially explain
> why I seem to be the only one seeing these "strange problems")?
Do you see something in *Messages* that isn't there without your
changes? You call Fformat, which conses a string, which can cause GC
or call some Lisp (depending on your customizations). If that causes
some echo-area message, it could maybe cause something like this.
Does this happen in "emacs -Q"?
Or it could be that some code that runs as result of this throws to
higher level and resets the quit flag.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-15 16:56 ` Eli Zaretskii
@ 2015-10-15 17:35 ` Tassilo Horn
2015-10-15 19:44 ` Eli Zaretskii
0 siblings, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-10-15 17:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael.albinus, 21313
Eli Zaretskii <eliz@gnu.org> writes:
> Do you see something in *Messages* that isn't there without your
> changes?
No.
> You call Fformat, which conses a string, which can cause GC or call
> some Lisp (depending on your customizations). If that causes some
> echo-area message, it could maybe cause something like this.
Ah, sorry, I forgot to tell you that this behavior is there also with
"emacs -Q" so we can rule out customizations.
Also, if there's some more direct way to print a readable representation
of a Lisp_Object from C, I can try with that.
> Or it could be that some code that runs as result of this throws to
> higher level and resets the quit flag.
But how could a GC (or maybe just some small slowdown induced by
printing) reset the quit flag?
Bye,
Tassilo
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-15 17:35 ` Tassilo Horn
@ 2015-10-15 19:44 ` Eli Zaretskii
2015-10-16 4:53 ` Tassilo Horn
0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2015-10-15 19:44 UTC (permalink / raw)
To: Tassilo Horn; +Cc: michael.albinus, 21313
> From: Tassilo Horn <tsdh@gnu.org>
> Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org
> Date: Thu, 15 Oct 2015 19:35:31 +0200
>
> > Or it could be that some code that runs as result of this throws to
> > higher level and resets the quit flag.
>
> But how could a GC (or maybe just some small slowdown induced by
> printing) reset the quit flag?
It can't, and that's not what I meant.
I think I found the problem: the call to Fformat eventually calls
print_object, which calls QUIT, which resets quit-flag.
So you need to change the beginning of read_char like this:
ptrdiff_t count = SPECPDL_INDEX ();
specbind (Qinhibit_quit, Qt);
AUTO_STRING (format, "%S");
printf ("record_char: %s\n", SSDATA (CALLN (Fformat, format, c)));
unbind_to (count, Qnil);
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-15 19:44 ` Eli Zaretskii
@ 2015-10-16 4:53 ` Tassilo Horn
2015-10-16 7:02 ` Eli Zaretskii
0 siblings, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-10-16 4:53 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael.albinus, 21313
Eli Zaretskii <eliz@gnu.org> writes:
>> But how could a GC (or maybe just some small slowdown induced by
>> printing) reset the quit flag?
>
> It can't, and that's not what I meant.
>
> I think I found the problem: the call to Fformat eventually calls
> print_object, which calls QUIT, which resets quit-flag.
I've seen it now. Well, that's not what I would have expected.
> So you need to change the beginning of read_char like this:
>
> ptrdiff_t count = SPECPDL_INDEX ();
> specbind (Qinhibit_quit, Qt);
> AUTO_STRING (format, "%S");
> printf ("record_char: %s\n", SSDATA (CALLN (Fformat, format, c)));
> unbind_to (count, Qnil);
Yes, that works. So that's the C version of (let ((inhibit-quit t))
...). So specbind creates a dynamic binding, and with unbind_to you pop
entries up to a given index again, right?
Bye,
Tassilo
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-16 4:53 ` Tassilo Horn
@ 2015-10-16 7:02 ` Eli Zaretskii
2015-10-16 7:45 ` Tassilo Horn
0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2015-10-16 7:02 UTC (permalink / raw)
To: Tassilo Horn; +Cc: michael.albinus, 21313
> From: Tassilo Horn <tsdh@gnu.org>
> Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org
> Date: Fri, 16 Oct 2015 06:53:19 +0200
>
> > I think I found the problem: the call to Fformat eventually calls
> > print_object, which calls QUIT, which resets quit-flag.
>
> I've seen it now. Well, that's not what I would have expected.
You should expect any potentially prolonged operation to call QUIT
somewhere in its loop. That's standard Emacs coding practice, meant
to make Emacs more responsive.
> > So you need to change the beginning of read_char like this:
> >
> > ptrdiff_t count = SPECPDL_INDEX ();
> > specbind (Qinhibit_quit, Qt);
> > AUTO_STRING (format, "%S");
> > printf ("record_char: %s\n", SSDATA (CALLN (Fformat, format, c)));
> > unbind_to (count, Qnil);
>
> Yes, that works. So that's the C version of (let ((inhibit-quit t))
> ...). So specbind creates a dynamic binding, and with unbind_to you pop
> entries up to a given index again, right?
Yes. See Flet (modulo the clutter) for a definitive evidence.
(Btw, unwind-protect is implemented using the same mechanism in C.)
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-16 7:02 ` Eli Zaretskii
@ 2015-10-16 7:45 ` Tassilo Horn
2015-10-16 8:23 ` Eli Zaretskii
0 siblings, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-10-16 7:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael.albinus, 21313
Eli Zaretskii <eliz@gnu.org> writes:
>> > I think I found the problem: the call to Fformat eventually calls
>> > print_object, which calls QUIT, which resets quit-flag.
>>
>> I've seen it now. Well, that's not what I would have expected.
>
> You should expect any potentially prolonged operation to call QUIT
> somewhere in its loop. That's standard Emacs coding practice, meant
> to make Emacs more responsive.
Ok, so QUIT; in C code basically means, here is a position where the
current lisp execution could be aborted. If it weren't in
print_object(), then you couldn't for example abort printing a list with
gazillions of elements and emacs would get stuck while doing so.
Looking at QUIT, the difference between my original code and the new one
is just when process_quit_flag() is called. process_quit_flag() always
signals quit. So with the new code, the signal is handled by the right
recipient. Who consumed (and discarded) it before?
Well, I think I just remember that I want to bind Qinhibit_quit to Qt
whenever I need to call Lisp functions from C.
>> > So you need to change the beginning of read_char like this:
>> >
>> > ptrdiff_t count = SPECPDL_INDEX ();
>> > specbind (Qinhibit_quit, Qt);
>> > AUTO_STRING (format, "%S");
>> > printf ("record_char: %s\n", SSDATA (CALLN (Fformat, format, c)));
>> > unbind_to (count, Qnil);
>>
>> Yes, that works. So that's the C version of (let ((inhibit-quit t))
>> ...). So specbind creates a dynamic binding, and with unbind_to you
>> pop entries up to a given index again, right?
>
> Yes. See Flet (modulo the clutter) for a definitive evidence.
>
> (Btw, unwind-protect is implemented using the same mechanism in C.)
Seen that, thanks!
Bye,
Tassilo
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-16 7:45 ` Tassilo Horn
@ 2015-10-16 8:23 ` Eli Zaretskii
2015-10-16 9:25 ` Tassilo Horn
0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2015-10-16 8:23 UTC (permalink / raw)
To: Tassilo Horn; +Cc: michael.albinus, 21313
> From: Tassilo Horn <tsdh@gnu.org>
> Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org
> Date: Fri, 16 Oct 2015 09:45:08 +0200
>
> Ok, so QUIT; in C code basically means, here is a position where the
> current lisp execution could be aborted. If it weren't in
> print_object(), then you couldn't for example abort printing a list with
> gazillions of elements and emacs would get stuck while doing so.
Correct.
> Looking at QUIT, the difference between my original code and the new one
> is just when process_quit_flag() is called. process_quit_flag() always
> signals quit. So with the new code, the signal is handled by the right
> recipient. Who consumed (and discarded) it before?
process_quit_flag itself:
void
process_quit_flag (void)
{
Lisp_Object flag = Vquit_flag;
Vquit_flag = Qnil; <<<<<<<<<<<<<<<<<<<<<<<
The gotcha here is that C-g is handled specially, i.e. not by
process_quit_flag, during processing of user input. That special
handling was bypassed because process_quit_flag attempted to process
it too early, and reseted the flag afterwards, thus disabling that
special processing.
> Well, I think I just remember that I want to bind Qinhibit_quit to Qt
> whenever I need to call Lisp functions from C.
In debugging code that isn't supposed to disrupt the control flow,
yes, that's a good rule. But if you write C code for "normal"
processing, then no, don't inhibit quitting like that just because you
call Lisp.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-16 8:23 ` Eli Zaretskii
@ 2015-10-16 9:25 ` Tassilo Horn
2015-10-16 10:11 ` Eli Zaretskii
0 siblings, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-10-16 9:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael.albinus, 21313
Eli Zaretskii <eliz@gnu.org> writes:
>> Looking at QUIT, the difference between my original code and the new
>> one is just when process_quit_flag() is called. process_quit_flag()
>> always signals quit. So with the new code, the signal is handled by
>> the right recipient. Who consumed (and discarded) it before?
>
> process_quit_flag itself:
>
> void
> process_quit_flag (void)
> {
> Lisp_Object flag = Vquit_flag;
> Vquit_flag = Qnil; <<<<<<<<<<<<<<<<<<<<<<<
>
> The gotcha here is that C-g is handled specially, i.e. not by
> process_quit_flag, during processing of user input.
Ok, I see.
> That special handling was bypassed because process_quit_flag attempted
> to process it too early, and reseted the flag afterwards, thus
> disabling that special processing.
What's a bit confusing is that it has been handled at least partially:
Quit was echoed but there was no "real" effect. So I guess somewhere
the quit signal emitted by process_quit_flag() was caught by whatever
code does echo messages and then re-signalled, and the top-level handler
discarded it because Vquit_flag was nil.
The question is if Quit should have been echoed at all? Well, it's good
for the user to see that emacs received it but then he'll wonder like me
why it has no effect. So maybe it should have echoed "Quit [ignored]"
or something like that.
>> Well, I think I just remember that I want to bind Qinhibit_quit to Qt
>> whenever I need to call Lisp functions from C.
>
> In debugging code that isn't supposed to disrupt the control flow,
> yes, that's a good rule. But if you write C code for "normal"
> processing, then no, don't inhibit quitting like that just because you
> call Lisp.
Yes, obviously.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-16 9:25 ` Tassilo Horn
@ 2015-10-16 10:11 ` Eli Zaretskii
2015-10-16 10:22 ` Tassilo Horn
0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2015-10-16 10:11 UTC (permalink / raw)
To: Tassilo Horn; +Cc: michael.albinus, 21313
> From: Tassilo Horn <tsdh@gnu.org>
> Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org
> Date: Fri, 16 Oct 2015 11:25:36 +0200
>
> What's a bit confusing is that it has been handled at least partially:
> Quit was echoed but there was no "real" effect. So I guess somewhere
> the quit signal emitted by process_quit_flag() was caught by whatever
> code does echo messages and then re-signalled, and the top-level handler
> discarded it because Vquit_flag was nil.
That's what process_quit_flag does.
> The question is if Quit should have been echoed at all? Well, it's good
> for the user to see that emacs received it but then he'll wonder like me
> why it has no effect. So maybe it should have echoed "Quit [ignored]"
> or something like that.
These situations are not supposed to happen. IOW, that was a bug.
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-16 10:11 ` Eli Zaretskii
@ 2015-10-16 10:22 ` Tassilo Horn
2015-10-29 7:43 ` Tassilo Horn
0 siblings, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-10-16 10:22 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael.albinus, 21313
Eli Zaretskii <eliz@gnu.org> writes:
>> The question is if Quit should have been echoed at all? Well, it's
>> good for the user to see that emacs received it but then he'll wonder
>> like me why it has no effect. So maybe it should have echoed "Quit
>> [ignored]" or something like that.
>
> These situations are not supposed to happen. IOW, that was a bug.
Ok, thanks again.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-16 10:22 ` Tassilo Horn
@ 2015-10-29 7:43 ` Tassilo Horn
2015-10-29 16:19 ` Eli Zaretskii
0 siblings, 1 reply; 44+ messages in thread
From: Tassilo Horn @ 2015-10-29 7:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael.albinus, 21313-done
Hi Eli,
I've run one week with master + my debugging code and then almost
another week with just master in order to rule out a Heisenbug that
vanishes when one tries to observe it. The problem didn't happen again;
it seems to have magically disappeared. So I'm closing this bug and in
the unlikely case that it'll pop up again, report a new one.
Thanks for all your assistance!
Bye,
Tassilo
^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#21313: 25.0.50; Strange errors from dbus-handle-event
2015-10-29 7:43 ` Tassilo Horn
@ 2015-10-29 16:19 ` Eli Zaretskii
0 siblings, 0 replies; 44+ messages in thread
From: Eli Zaretskii @ 2015-10-29 16:19 UTC (permalink / raw)
To: Tassilo Horn; +Cc: michael.albinus, 21313-done
> From: Tassilo Horn <tsdh@gnu.org>
> Cc: michael.albinus@gmx.de, 21313-done@debbugs.gnu.org
> Date: Thu, 29 Oct 2015 08:43:29 +0100
>
> I've run one week with master + my debugging code and then almost
> another week with just master in order to rule out a Heisenbug that
> vanishes when one tries to observe it. The problem didn't happen again;
> it seems to have magically disappeared. So I'm closing this bug and in
> the unlikely case that it'll pop up again, report a new one.
OK, thanks.
^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2015-10-29 16:19 UTC | newest]
Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).