* 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 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 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: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 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: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 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 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).