From unknown Mon Jun 23 07:49:16 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#21313 <21313@debbugs.gnu.org> To: bug#21313 <21313@debbugs.gnu.org> Subject: Status: 25.0.50; Strange errors from dbus-handle-event Reply-To: bug#21313 <21313@debbugs.gnu.org> Date: Mon, 23 Jun 2025 14:49:16 +0000 retitle 21313 25.0.50; Strange errors from dbus-handle-event reassign 21313 emacs submitter 21313 Tassilo Horn severity 21313 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 21 12:27:46 2015 Received: (at submit) by debbugs.gnu.org; 21 Aug 2015 16:27:46 +0000 Received: from localhost ([127.0.0.1]:34698 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZSpAN-00047j-Sq for submit@debbugs.gnu.org; Fri, 21 Aug 2015 12:27:46 -0400 Received: from eggs.gnu.org ([208.118.235.92]:53719) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZSpAJ-00047Z-Uw for submit@debbugs.gnu.org; Fri, 21 Aug 2015 12:27:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZSpAD-0004My-GD for submit@debbugs.gnu.org; Fri, 21 Aug 2015 12:27:39 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:55819) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSpAD-0004Kl-E0 for submit@debbugs.gnu.org; Fri, 21 Aug 2015 12:27:33 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34695) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSp7B-0002GP-2G for bug-gnu-emacs@gnu.org; Fri, 21 Aug 2015 12:24:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZSp77-0003DY-Mq for bug-gnu-emacs@gnu.org; Fri, 21 Aug 2015 12:24:24 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:34672) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSp77-0003DG-E3 for bug-gnu-emacs@gnu.org; Fri, 21 Aug 2015 12:24:21 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 2302320651 for ; Fri, 21 Aug 2015 12:24:21 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Fri, 21 Aug 2015 12:24:21 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=b+ntzqjOIr/YYhGlxweSlpfBUG8=; b=g9wdG eKiU68JQxos7TQTyfJHj4CGTAQnZqgCTl/Y4YV6my4/Umonb9cm4HQQc0ERHE79x dctH35ACcFndnXrMrd4ZN63FbXLbtuD9h7BdpSTEo2yRn59k2YHuJjTtNp+dDH9x bzxfNKGZAlmb0Fwm40Tk1jgL202tCpOVvEqKIA= X-Sasl-enc: jO04AiJ8MFi794AxpLvGLvoRuOte4eJ2U/1aP29UJlqj 1440174260 Received: from thinkpad-t440p (unknown [2.163.198.26]) by mail.messagingengine.com (Postfix) with ESMTPA id 61EA868012A for ; Fri, 21 Aug 2015 12:24:20 -0400 (EDT) From: Tassilo Horn To: bug-gnu-emacs@gnu.org Subject: 25.0.50; Strange errors from dbus-handle-event Date: Fri, 21 Aug 2015 18:24:18 +0200 Message-ID: <877foo4nkd.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.8 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.8 (-----) 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 ["=E2= =89=B1 \\ngeq" LaTeX-math-ngeq t]) dbus-handle-event((dbus-event ["=E2=89=AF \\ngtr" LaTeX-math-ngtr t] ["= =E2=89=B1 \\ngeq" LaTeX-math-ngeq t] ["\\ngeqslant" LaTeX-math-ngeqslant t]= ["\\ngeqq" LaTeX-math-ngeqq t] ["=E2=AA=88 \\gneq" LaTeX-math-gneq t] ["= =E2=89=A9 \\gneqq" LaTeX-math-gneqq t] ["\\gvertneqq" LaTeX-math-gvertneqq = t] ["=E2=8B=A7 \\gnsim" LaTeX-math-gnsim t] ["=E2=AA=8A \\gnapprox" LaTeX-m= ath-gnapprox t] ["=E2=8A=81 \\nsucc" LaTeX-math-nsucc t] ["\\nsucceq" LaTeX= -math-nsucceq t] ["=E2=8B=A9 \\succnsim" LaTeX-math-succnsim t] ["=E2=AA=BA= \\succnapprox" LaTeX-math-succnapprox t] ["=E2=89=87 \\ncong" LaTeX-math-n= cong t] ["=E2=88=A6 \\nshortparallel" LaTeX-math-nshortparallel t] ["=E2=88= =A6 \\nparallel" LaTeX-math-nparallel t] ["=E2=8A=AD \\nvDash" LaTeX-math-n= vDash t] ["=E2=8A=AF \\nVDash" LaTeX-math-nVDash t] ["=E2=8B=AB \\ntriangle= right" LaTeX-math-ntriangleright t] ["=E2=8B=AD \\ntrianglerighteq" LaTeX-m= ath-ntrianglerighteq t] ["=E2=8A=89 \\nsupseteq" LaTeX-math-nsupseteq t] ["= \\nsupseteqq" LaTeX-math-nsupseteqq t] ["=E2=8A=8B \\supsetneq" LaTeX-math-= supsetneq t] ["\\varsupsetneq" LaTeX-math-varsupsetneq t] ["=E2=AB=8C \\sup= setneqq" LaTeX-math-supsetneqq t] ["\\varsupsetneqq" LaTeX-math-varsupsetne= qq t])) funcall-interactively(dbus-handle-event (dbus-event ["=E2=89=AF \\ngtr" L= aTeX-math-ngtr t] ["=E2=89=B1 \\ngeq" LaTeX-math-ngeq t] ["\\ngeqslant" LaT= eX-math-ngeqslant t] ["\\ngeqq" LaTeX-math-ngeqq t] ["=E2=AA=88 \\gneq" LaT= eX-math-gneq t] ["=E2=89=A9 \\gneqq" LaTeX-math-gneqq t] ["\\gvertneqq" LaT= eX-math-gvertneqq t] ["=E2=8B=A7 \\gnsim" LaTeX-math-gnsim t] ["=E2=AA=8A \= \gnapprox" LaTeX-math-gnapprox t] ["=E2=8A=81 \\nsucc" LaTeX-math-nsucc t] = ["\\nsucceq" LaTeX-math-nsucceq t] ["=E2=8B=A9 \\succnsim" LaTeX-math-succn= sim t] ["=E2=AA=BA \\succnapprox" LaTeX-math-succnapprox t] ["=E2=89=87 \\n= cong" LaTeX-math-ncong t] ["=E2=88=A6 \\nshortparallel" LaTeX-math-nshortpa= rallel t] ["=E2=88=A6 \\nparallel" LaTeX-math-nparallel t] ["=E2=8A=AD \\nv= Dash" LaTeX-math-nvDash t] ["=E2=8A=AF \\nVDash" LaTeX-math-nVDash t] ["=E2= =8B=AB \\ntriangleright" LaTeX-math-ntriangleright t] ["=E2=8B=AD \\ntriang= lerighteq" LaTeX-math-ntrianglerighteq t] ["=E2=8A=89 \\nsupseteq" LaTeX-ma= th-nsupseteq t] ["\\nsupseteqq" LaTeX-math-nsupseteqq t] ["=E2=8A=8B \\sups= etneq" LaTeX-math-supsetneq t] ["\\varsupsetneq" LaTeX-math-varsupsetneq t]= ["=E2=AB=8C \\supsetneqq" LaTeX-math-supsetneqq t] ["\\varsupsetneqq" LaTe= X-math-varsupsetneqq t])) call-interactively(dbus-handle-event nil [(dbus-event ["=E2=89=AF \\ngtr"= LaTeX-math-ngtr t] ["=E2=89=B1 \\ngeq" LaTeX-math-ngeq t] ["\\ngeqslant" L= aTeX-math-ngeqslant t] ["\\ngeqq" LaTeX-math-ngeqq t] ["=E2=AA=88 \\gneq" L= aTeX-math-gneq t] ["=E2=89=A9 \\gneqq" LaTeX-math-gneqq t] ["\\gvertneqq" L= aTeX-math-gvertneqq t] ["=E2=8B=A7 \\gnsim" LaTeX-math-gnsim t] ["=E2=AA=8A= \\gnapprox" LaTeX-math-gnapprox t] ["=E2=8A=81 \\nsucc" LaTeX-math-nsucc t= ] ["\\nsucceq" LaTeX-math-nsucceq t] ["=E2=8B=A9 \\succnsim" LaTeX-math-suc= cnsim t] ["=E2=AA=BA \\succnapprox" LaTeX-math-succnapprox t] ["=E2=89=87 \= \ncong" LaTeX-math-ncong t] ["=E2=88=A6 \\nshortparallel" LaTeX-math-nshort= parallel t] ["=E2=88=A6 \\nparallel" LaTeX-math-nparallel t] ["=E2=8A=AD \\= nvDash" LaTeX-math-nvDash t] ["=E2=8A=AF \\nVDash" LaTeX-math-nVDash t] ["= =E2=8B=AB \\ntriangleright" LaTeX-math-ntriangleright t] ["=E2=8B=AD \\ntri= anglerighteq" LaTeX-math-ntrianglerighteq t] ["=E2=8A=89 \\nsupseteq" LaTeX= -math-nsupseteq t] ["\\nsupseteqq" LaTeX-math-nsupseteqq t] ["=E2=8A=8B \\s= upsetneq" LaTeX-math-supsetneq t] ["\\varsupsetneq" LaTeX-math-varsupsetneq= t] ["=E2=AB=8C \\supsetneqq" LaTeX-math-supsetneqq t] ["\\varsupsetneqq" L= aTeX-math-varsupsetneqq t])]) command-execute(dbus-handle-event nil [(dbus-event ["=E2=89=AF \\ngtr" La= TeX-math-ngtr t] ["=E2=89=B1 \\ngeq" LaTeX-math-ngeq t] ["\\ngeqslant" LaTe= X-math-ngeqslant t] ["\\ngeqq" LaTeX-math-ngeqq t] ["=E2=AA=88 \\gneq" LaTe= X-math-gneq t] ["=E2=89=A9 \\gneqq" LaTeX-math-gneqq t] ["\\gvertneqq" LaTe= X-math-gvertneqq t] ["=E2=8B=A7 \\gnsim" LaTeX-math-gnsim t] ["=E2=AA=8A \\= gnapprox" LaTeX-math-gnapprox t] ["=E2=8A=81 \\nsucc" LaTeX-math-nsucc t] [= "\\nsucceq" LaTeX-math-nsucceq t] ["=E2=8B=A9 \\succnsim" LaTeX-math-succns= im t] ["=E2=AA=BA \\succnapprox" LaTeX-math-succnapprox t] ["=E2=89=87 \\nc= ong" LaTeX-math-ncong t] ["=E2=88=A6 \\nshortparallel" LaTeX-math-nshortpar= allel t] ["=E2=88=A6 \\nparallel" LaTeX-math-nparallel t] ["=E2=8A=AD \\nvD= ash" LaTeX-math-nvDash t] ["=E2=8A=AF \\nVDash" LaTeX-math-nVDash t] ["=E2= =8B=AB \\ntriangleright" LaTeX-math-ntriangleright t] ["=E2=8B=AD \\ntriang= lerighteq" LaTeX-math-ntrianglerighteq t] ["=E2=8A=89 \\nsupseteq" LaTeX-ma= th-nsupseteq t] ["\\nsupseteqq" LaTeX-math-nsupseteqq t] ["=E2=8A=8B \\sups= etneq" LaTeX-math-supsetneq t] ["\\varsupsetneq" LaTeX-math-varsupsetneq t]= ["=E2=AB=8C \\supsetneqq" LaTeX-math-supsetneqq t] ["\\varsupsetneqq" LaTe= X-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, , 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] [newline] C-k [kill-line] ... C-k [kill-line] [previous-line] [previous-line] [previous-line] C-k [kill-line] ... C-k [kill-line] M-x [counsel-M-x] [ivy-done] --8<---------------cut here---------------end--------------->8--- I did NOT press 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 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=3D-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/e= lpa/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/forma= t-spec ~/Repos/el/gnus/lisp/password-cache hides /home/horn/Repos/el/emacs/lisp/pa= ssword-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/textmode= s/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/rfc21= 04 ~/Repos/el/gnus/lisp/sasl-ntlm hides /home/horn/Repos/el/emacs/lisp/net/sas= l-ntlm ~/Repos/el/gnus/lisp/sasl-cram hides /home/horn/Repos/el/emacs/lisp/net/sas= l-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/ne= t/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/s= asl-digest ~/Repos/el/gnus/lisp/uudecode hides /home/horn/Repos/el/emacs/lisp/mail/uud= ecode ~/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/has= hcash ~/Repos/el/gnus/lisp/canlock hides /home/horn/Repos/el/emacs/lisp/gnus/canl= ock ~/Repos/el/gnus/lisp/nneething hides /home/horn/Repos/el/emacs/lisp/gnus/nn= eething ~/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-u= til ~/Repos/el/gnus/lisp/rfc2047 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2= 047 ~/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/gnu= s-cus ~/Repos/el/gnus/lisp/gnus-range hides /home/horn/Repos/el/emacs/lisp/gnus/g= nus-range ~/Repos/el/gnus/lisp/gnus-int hides /home/horn/Repos/el/emacs/lisp/gnus/gnu= s-int ~/Repos/el/gnus/lisp/gnus-cloud hides /home/horn/Repos/el/emacs/lisp/gnus/g= nus-cloud ~/Repos/el/gnus/lisp/spam-stat hides /home/horn/Repos/el/emacs/lisp/gnus/sp= am-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/g= nus-mlspl ~/Repos/el/gnus/lisp/deuglify hides /home/horn/Repos/el/emacs/lisp/gnus/deu= glify ~/Repos/el/gnus/lisp/gnus-gravatar hides /home/horn/Repos/el/emacs/lisp/gnu= s/gnus-gravatar ~/Repos/el/gnus/lisp/nngateway hides /home/horn/Repos/el/emacs/lisp/gnus/nn= gateway ~/Repos/el/gnus/lisp/ietf-drums hides /home/horn/Repos/el/emacs/lisp/gnus/i= etf-drums ~/Repos/el/gnus/lisp/mail-parse hides /home/horn/Repos/el/emacs/lisp/gnus/m= ail-parse ~/Repos/el/gnus/lisp/gnus-salt hides /home/horn/Repos/el/emacs/lisp/gnus/gn= us-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/g= nus-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/m= esscompat ~/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/nn= maildir ~/Repos/el/gnus/lisp/nnheader hides /home/horn/Repos/el/emacs/lisp/gnus/nnh= eader ~/Repos/el/gnus/lisp/gnus-cite hides /home/horn/Repos/el/emacs/lisp/gnus/gn= us-cite ~/Repos/el/gnus/lisp/nndiary hides /home/horn/Repos/el/emacs/lisp/gnus/nndi= ary ~/Repos/el/gnus/lisp/gnus-diary hides /home/horn/Repos/el/emacs/lisp/gnus/g= nus-diary ~/Repos/el/gnus/lisp/nnfolder hides /home/horn/Repos/el/emacs/lisp/gnus/nnf= older ~/Repos/el/gnus/lisp/gnus-art hides /home/horn/Repos/el/emacs/lisp/gnus/gnu= s-art ~/Repos/el/gnus/lisp/gnus-demon hides /home/horn/Repos/el/emacs/lisp/gnus/g= nus-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/m= m-partial ~/Repos/el/gnus/lisp/gnus-registry hides /home/horn/Repos/el/emacs/lisp/gnu= s/gnus-registry ~/Repos/el/gnus/lisp/gnus-icalendar hides /home/horn/Repos/el/emacs/lisp/gn= us/gnus-icalendar ~/Repos/el/gnus/lisp/compface hides /home/horn/Repos/el/emacs/lisp/gnus/com= pface ~/Repos/el/gnus/lisp/gnus-fun hides /home/horn/Repos/el/emacs/lisp/gnus/gnu= s-fun ~/Repos/el/gnus/lisp/gnus-start hides /home/horn/Repos/el/emacs/lisp/gnus/g= nus-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/g= nus-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/gn= us-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/nn= virtual ~/Repos/el/gnus/lisp/gnus-notifications hides /home/horn/Repos/el/emacs/lis= p/gnus/gnus-notifications ~/Repos/el/gnus/lisp/nnspool hides /home/horn/Repos/el/emacs/lisp/gnus/nnsp= ool ~/Repos/el/gnus/lisp/gnus-group hides /home/horn/Repos/el/emacs/lisp/gnus/g= nus-group ~/Repos/el/gnus/lisp/gnus-bcklg hides /home/horn/Repos/el/emacs/lisp/gnus/g= nus-bcklg ~/Repos/el/gnus/lisp/gnus-util hides /home/horn/Repos/el/emacs/lisp/gnus/gn= us-util ~/Repos/el/gnus/lisp/gnus-sieve hides /home/horn/Repos/el/emacs/lisp/gnus/g= nus-sieve ~/Repos/el/gnus/lisp/nndraft hides /home/horn/Repos/el/emacs/lisp/gnus/nndr= aft ~/Repos/el/gnus/lisp/nnagent hides /home/horn/Repos/el/emacs/lisp/gnus/nnag= ent ~/Repos/el/gnus/lisp/gnus-spec hides /home/horn/Repos/el/emacs/lisp/gnus/gn= us-spec ~/Repos/el/gnus/lisp/gnus-bookmark hides /home/horn/Repos/el/emacs/lisp/gnu= s/gnus-bookmark ~/Repos/el/gnus/lisp/mml1991 hides /home/horn/Repos/el/emacs/lisp/gnus/mml1= 991 ~/Repos/el/gnus/lisp/rfc2231 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2= 231 ~/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/gn= us-undo ~/Repos/el/gnus/lisp/ecomplete hides /home/horn/Repos/el/emacs/lisp/gnus/ec= omplete ~/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/mess= age ~/Repos/el/gnus/lisp/mml-smime hides /home/horn/Repos/el/emacs/lisp/gnus/mm= l-smime ~/Repos/el/gnus/lisp/gnus-eform hides /home/horn/Repos/el/emacs/lisp/gnus/g= nus-eform ~/Repos/el/gnus/lisp/gnus-agent hides /home/horn/Repos/el/emacs/lisp/gnus/g= nus-agent ~/Repos/el/gnus/lisp/gnus-logic hides /home/horn/Repos/el/emacs/lisp/gnus/g= nus-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/sta= rttls ~/Repos/el/gnus/lisp/gnus-dired hides /home/horn/Repos/el/emacs/lisp/gnus/g= nus-dired ~/Repos/el/gnus/lisp/nnbabyl hides /home/horn/Repos/el/emacs/lisp/gnus/nnba= byl ~/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/gnu= s-win ~/Repos/el/gnus/lisp/gnus-async hides /home/horn/Repos/el/emacs/lisp/gnus/g= nus-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/gn= us-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/mml2= 015 ~/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/gnu= s-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/m= ail-prsvr ~/Repos/el/gnus/lisp/nnmairix hides /home/horn/Repos/el/emacs/lisp/gnus/nnm= airix ~/Repos/el/gnus/lisp/plstore hides /home/horn/Repos/el/emacs/lisp/gnus/plst= ore ~/Repos/el/gnus/lisp/rfc2045 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2= 045 ~/Repos/el/gnus/lisp/gnus-msg hides /home/horn/Repos/el/emacs/lisp/gnus/gnu= s-msg ~/Repos/el/gnus/lisp/spam-wash hides /home/horn/Repos/el/emacs/lisp/gnus/sp= am-wash ~/Repos/el/gnus/lisp/gnus-score hides /home/horn/Repos/el/emacs/lisp/gnus/g= nus-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-v= iew ~/Repos/el/gnus/lisp/sieve-mode hides /home/horn/Repos/el/emacs/lisp/gnus/s= ieve-mode ~/Repos/el/gnus/lisp/html2text hides /home/horn/Repos/el/emacs/lisp/gnus/ht= ml2text ~/Repos/el/gnus/lisp/gnus-ems hides /home/horn/Repos/el/emacs/lisp/gnus/gnu= s-ems ~/Repos/el/gnus/lisp/registry hides /home/horn/Repos/el/emacs/lisp/gnus/reg= istry ~/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/gra= vatar ~/Repos/el/gnus/lisp/flow-fill hides /home/horn/Repos/el/emacs/lisp/gnus/fl= ow-fill ~/Repos/el/gnus/lisp/gmm-utils hides /home/horn/Repos/el/emacs/lisp/gnus/gm= m-utils ~/Repos/el/gnus/lisp/mailcap hides /home/horn/Repos/el/emacs/lisp/gnus/mail= cap ~/Repos/el/gnus/lisp/gnus-delay hides /home/horn/Repos/el/emacs/lisp/gnus/g= nus-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/m= m-archive ~/Repos/el/gnus/lisp/rfc1843 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc1= 843 ~/Repos/el/gnus/lisp/gnus-kill hides /home/horn/Repos/el/emacs/lisp/gnus/gn= us-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/s= core-mode ~/Repos/el/gnus/lisp/gnus-topic hides /home/horn/Repos/el/emacs/lisp/gnus/g= nus-topic ~/Repos/el/gnus/lisp/gnus-cache hides /home/horn/Repos/el/emacs/lisp/gnus/g= nus-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/gn= us-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/n= nregistry ~/Repos/el/gnus/lisp/gnus-dup hides /home/horn/Repos/el/emacs/lisp/gnus/gnu= s-dup ~/Repos/el/gnus/lisp/parse-time hides /home/horn/Repos/el/emacs/lisp/calend= ar/parse-time ~/Repos/el/gnus/lisp/time-date hides /home/horn/Repos/el/emacs/lisp/calenda= r/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)) From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 07 11:15:27 2015 Received: (at control) by debbugs.gnu.org; 7 Sep 2015 15:15:28 +0000 Received: from localhost ([127.0.0.1]:51764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYy8l-0006Wx-F3 for submit@debbugs.gnu.org; Mon, 07 Sep 2015 11:15:27 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:38435) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYy8i-0006Wf-OV; Mon, 07 Sep 2015 11:15:25 -0400 Received: by wiclk2 with SMTP id lk2so87383634wic.1; Mon, 07 Sep 2015 08:15:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:references:cc:gmane-reply-to-list:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=LAEY+84coJ3/HBG287KSgS1I2oaW7aNIbSU2GXMtcdg=; b=07gBE1NyOXW9t04nt9khBdYViLAevNZOmvMojyCcrZ5HFsC71ofIZdwyjdardNDLEN JOxgY8BiqkYf3cHjhHe3fQqskOAIbsN+zLNoGeV6CLr8D5bJP8wykLwRRCUkwCltV1A/ CFshxGHDeUaWNfUpSoCbu3K4QQMlQcytlgm5L/L8XnF4ERX8KtXojOLZ0sMEKbF6SHrd zT+LAzZHtYDBOnA0IJ3foYnV7iw5XY3QMsNx/2fFaRvy0v3VoAER1Z3BugJJkatC1cbR nq8dvmiWYlGrf72cyJc0y9MCL1mG8LPqDgSnHRTz0fScZVk9jtZ1V9NjLpla2ERSKRxb OY0w== X-Received: by 10.180.38.110 with SMTP id f14mr35241741wik.62.1441638924104; Mon, 07 Sep 2015 08:15:24 -0700 (PDT) Received: from rpluim-ubuntu ([213.30.189.66]) by smtp.gmail.com with ESMTPSA id gt10sm20746403wib.20.2015.09.07.08.15.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Sep 2015 08:15:23 -0700 (PDT) From: Robert Pluim To: Eli Zaretskii Subject: Re: bug#21337: 25.0.50; inotify error message References: <87k2skyjf2.fsf@gmail.com> <83d1ychefg.fsf@gnu.org> <87oahw8xmv.fsf@gmail.com> <83a8tghcgr.fsf@gnu.org> <87twrobpet.fsf@gmail.com> <836144hagi.fsf@gnu.org> <87io84pmec.fsf@gmail.com> <83si78fpi5.fsf@gnu.org> <87twrm2db4.fsf@gmail.com> <87vbbmzoc7.fsf@gnu.org> <87vbbm7jzo.fsf@gmail.com> <83zj0y6zpq.fsf@gnu.org> X-Debbugs-No-Ack: yes Gmane-Reply-To-List: yes Date: Mon, 07 Sep 2015 17:15:22 +0200 In-Reply-To: <83zj0y6zpq.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 07 Sep 2015 18:01:05 +0300") Message-ID: <874mj6xnud.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: control Cc: 21337@debbugs.gnu.org, tsdh@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) forcemerge 21337 21313 stop Eli Zaretskii writes: > Provided GnuTLS is compiled in -- which it is in this case. > > So feel free to merge these two bugs and close the other one. I *think* this should close 21313 as well. admin/notes/bugtracker does not suffer from being too short. Thanks Robert From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 09 13:55:54 2015 Received: (at control) by debbugs.gnu.org; 9 Sep 2015 17:55:54 +0000 Received: from localhost ([127.0.0.1]:54117 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZjb8-0002xm-2i for submit@debbugs.gnu.org; Wed, 09 Sep 2015 13:55:54 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:50138) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZjb5-0002xc-6x for control@debbugs.gnu.org; Wed, 09 Sep 2015 13:55:52 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NUF0070082VIQ00@mtaout27.012.net.il> for control@debbugs.gnu.org; Wed, 09 Sep 2015 20:52:27 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUF00M4O8BFR2B0@mtaout27.012.net.il> for control@debbugs.gnu.org; Wed, 09 Sep 2015 20:52:27 +0300 (IDT) Date: Wed, 09 Sep 2015 20:55:44 +0300 From: Eli Zaretskii Subject: Re: bug#21337: 25.0.50; inotify error message In-reply-to: <87twr35yhs.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: control@debbugs.gnu.org Message-id: <83lhcf5vfj.fsf@gnu.org> References: <87k2skyjf2.fsf@gmail.com> <83d1ychefg.fsf@gnu.org> <87oahw8xmv.fsf@gmail.com> <83a8tghcgr.fsf@gnu.org> <87twrobpet.fsf@gmail.com> <836144hagi.fsf@gnu.org> <87io84pmec.fsf@gmail.com> <83si78fpi5.fsf@gnu.org> <87twrm2db4.fsf@gmail.com> <87vbbmzoc7.fsf@gnu.org> <87vbbm7jzo.fsf@gmail.com> <83zj0y6zpq.fsf@gnu.org> <874mj6xnud.fsf@gmail.com> <87twr35yhs.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) unmerge 21313 reopen 21313 thanks From unknown Mon Jun 23 07:49:16 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: Did not alter fixed versions and reopened. Date: Wed, 09 Sep 2015 17:56:02 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # Did not alter fixed versions and reopened. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 09 16:43:34 2015 Received: (at 21313) by debbugs.gnu.org; 9 Sep 2015 20:43:34 +0000 Received: from localhost ([127.0.0.1]:54235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZmDN-0000dC-GS for submit@debbugs.gnu.org; Wed, 09 Sep 2015 16:43:33 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:44460) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZmDL-0000d5-NN for 21313@debbugs.gnu.org; Wed, 09 Sep 2015 16:43:32 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 85C7120295 for <21313@debbugs.gnu.org>; Wed, 9 Sep 2015 16:43:31 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Wed, 09 Sep 2015 16:43:31 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=eze3VSUtoRbxS9wj6RnTMwRntqw=; b=i8cRe Qyowg3dxNZLuw6rO+UDdQnLgLh3XRDiheJN1FTiAkqZZk978JVZW1pvmtmlkDi33 r9OmrjIin1+d50pW6DNal3XnpzGc6MY+cmP0wtlDXQEBHzZ+eGVCb5y2pA+I1qJS QMNoafg6BeLPoK2F3palACjgiMKay+HKIbwu10= X-Sasl-enc: 7rMijMJ5YDK4mVOjWug/jgRJpwb0N1ztDPO2yIhraoyd 1441831411 Received: from thinkpad-t440p (unknown [2.161.206.107]) by mail.messagingengine.com (Postfix) with ESMTPA id 01C5D680197 for <21313@debbugs.gnu.org>; Wed, 9 Sep 2015 16:43:30 -0400 (EDT) From: Tassilo Horn To: 21313@debbugs.gnu.org Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> Date: Wed, 09 Sep 2015 22:43:28 +0200 In-Reply-To: <877foo4nkd.fsf@gnu.org> (Tassilo Horn's message of "Fri, 21 Aug 2015 18:24:18 +0200") Message-ID: <87wpvzs4r3.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21313 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) 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 "", 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 , ---Type to continue, or q to quit--- handlers=18912, hfun=0x551ea6 ) 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 , 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--- From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 11 08:29:01 2015 Received: (at 21313) by debbugs.gnu.org; 11 Sep 2015 12:29:01 +0000 Received: from localhost ([127.0.0.1]:56233 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaNRr-0006Sc-49 for submit@debbugs.gnu.org; Fri, 11 Sep 2015 08:29:01 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:60243) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaNRm-0006SS-OQ for 21313@debbugs.gnu.org; Fri, 11 Sep 2015 08:28:57 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 8EC1820329 for <21313@debbugs.gnu.org>; Fri, 11 Sep 2015 08:28:54 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Fri, 11 Sep 2015 08:28:54 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=fylPOETd6yMmNSQV0VsN0aMSe4o=; b=Lj+ZK v7cWCm4F/6MeJaOmTPhKpsoKdZ28ybgZ9VtxV0G+Sqsdl245+ycHNX7/ypIV6a7x NERmCjkayb4/uwNglR/J+7sI5+xpsJB5zkisNi3ViiAles0CYrWaM2RiteSp/GE8 pxhVbHep1rQwcf6RKoP5SDGfbsJISmyKURl2ZU= X-Sasl-enc: WUJO4yKbKxA8DgVjkU1Wa/xMwBBt9JuyFvxHRKxFWfu6 1441974533 Received: from thinkpad-t440p (unknown [2.161.110.122]) by mail.messagingengine.com (Postfix) with ESMTPA id 89D4BC00294 for <21313@debbugs.gnu.org>; Fri, 11 Sep 2015 08:28:53 -0400 (EDT) From: Tassilo Horn To: 21313@debbugs.gnu.org Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> Date: Fri, 11 Sep 2015 14:28:51 +0200 In-Reply-To: <87wpvzs4r3.fsf@gnu.org> (Tassilo Horn's message of "Wed, 09 Sep 2015 22:43:28 +0200") Message-ID: <87bnd9cf7g.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21313 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) 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 ) 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 to continue, or q 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 , 0x632fcd , 0x632fcf , 0x632fd1 , 0x632fd3 , 0x632fd3 , 0x633033 , 0x6330a6 , 0x62f0f0 , 0x62f0f2 , 0x62f0f4 , 0x62f0f6 , 0x62f0f8 , 0x62f0f8 , 0x62f0fe , 0x62f0b3 , 0x62f575 , 0x62f577 , 0x62f579 , 0x62f57b , 0x62f57d , 0x62f57d , 0x62f5be , 0x62f583 , 0x62f776 , 0x62f778 , 0x62f77a , 0x62f77c , 0x62f77e , 0x62f77e , 0x62f71e , 0x62f73b , 0x62f838 , 0x62f83a , 0x62f83c , 0x62f83e , 0x62f840 , 0x62f840 , 0x62f7e0 , 0x62f7fd , 0x62f8fa , 0x62f8fc , 0x62f8fe , 0x62f900 , 0x62f902 , 0x62f902 , 0x62f8a2 , 0x62f8bf , 0x6309b7 , 0x63078c , 0x630783 , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x630bdd , 0x630cb6 , 0x630d14 , 0x630d73 , 0x630dd6 , 0x62f3ef , 0x62f465 , 0x630e4b , 0x62f346 , 0x62f4cb , ---Type to continue, or q to quit--- 0x630eb1 , 0x630f17 , 0x630f5d , 0x630fc3 , 0x631010 , 0x6310dd , 0x631123 , 0x631189 , 0x63120c , 0x631252 , 0x631298 , 0x6312fe , 0x631364 , 0x6313ca , 0x63144d , 0x63149a , 0x6314e7 , 0x6315b4 , 0x631645 , 0x6316d6 , 0x631927 , 0x631992 , 0x6319fd , 0x631a68 , 0x631ad3 , 0x631b20 , 0x631bb2 , 0x631bff , 0x631c4c , 0x631c99 , 0x631d99 , 0x630620 , 0x631df6 , 0x631e3c , 0x631f04 , 0x631f61 , 0x631fbe , 0x632004 , 0x632050 , 0x63209c , 0x6320f0 , 0x632f6d , 0x632146 , 0x632187 , 0x6321c8 , 0x632209 , 0x63224a , 0x63228b , 0x630620 , 0x632f6d , 0x6322d1 , 0x63231f , 0x632365 , 0x6323ab , 0x632411 , 0x632477 , 0x6324bd , 0x6325ad , 0x632613 , 0x632679 , 0x6326df , 0x632720 , 0x632f6d , 0x630557 , 0x62f9a7 , 0x62f1e6 , 0x62fada , 0x62fc3a , 0x62fd8e , 0x6304e8 , 0x630525 , 0x62f6d0 , 0x6305e1 , 0x630652 , 0x6306dc , 0x63071b , 0x6309f6 , 0x630a78 , 0x630afb , 0x630b5c , 0x62f95e , 0x632766 , 0x6327e9 , 0x63282f , 0x632875 , 0x6328bb , 0x632901 , 0x632967 , 0x6329cd , 0x632a33 , 0x632a99 , 0x632bd8 , 0x632c3e , 0x632ca4 , 0x632cea , 0x632d50 , 0x632db6 , 0x632e0a , 0x632e5e , 0x631ce6 , 0x631d33 , 0x632eab , 0x632f0e , 0x632f6d , 0x62fee2 , 0x62ffe8 , 0x63012d , 0x630272 , 0x6303ad , 0x63105d , 0x631534 , 0x631e84 , 0x633140 , 0x6331b6 , ---Type to continue, or q to quit--- 0x632f6d , 0x632f6d , 0x633253 , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x6332db } 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 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 , 0x632fcd , 0x632fcf , 0x632fd1 , 0x632fd3 , 0x632fd3 , 0x633033 , 0x6330a6 , 0x62f0f0 , 0x62f0f2 , 0x62f0f4 , 0x62f0f6 , 0x62f0f8 , 0x62f0f8 , 0x62f0fe , 0x62f0b3 , 0x62f575 , 0x62f577 , 0x62f579 , 0x62f57b , 0x62f57d , 0x62f57d , 0x62f5be , 0x62f583 , 0x62f776 , 0x62f778 , 0x62f77a , 0x62f77c , 0x62f77e , 0x62f77e , 0x62f71e , 0x62f73b , ---Type to continue, or q to quit--- 0x62f838 , 0x62f83a , 0x62f83c , 0x62f83e , 0x62f840 , 0x62f840 , 0x62f7e0 , 0x62f7fd , 0x62f8fa , 0x62f8fc , 0x62f8fe , 0x62f900 , 0x62f902 , 0x62f902 , 0x62f8a2 , 0x62f8bf , 0x6309b7 , 0x63078c , 0x630783 , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x630bdd , 0x630cb6 , 0x630d14 , 0x630d73 , 0x630dd6 , 0x62f3ef , 0x62f465 , 0x630e4b , 0x62f346 , 0x62f4cb , 0x630eb1 , 0x630f17 , 0x630f5d , 0x630fc3 , 0x631010 , 0x6310dd , 0x631123 , 0x631189 , 0x63120c , 0x631252 , 0x631298 , 0x6312fe , 0x631364 , 0x6313ca , 0x63144d , 0x63149a , 0x6314e7 , 0x6315b4 , 0x631645 , 0x6316d6 , 0x631927 , 0x631992 , 0x6319fd , 0x631a68 , 0x631ad3 , 0x631b20 , 0x631bb2 , 0x631bff , 0x631c4c , 0x631c99 , 0x631d99 , 0x630620 , 0x631df6 , 0x631e3c , 0x631f04 , 0x631f61 , 0x631fbe , 0x632004 , 0x632050 , 0x63209c , 0x6320f0 , 0x632f6d , 0x632146 , 0x632187 , 0x6321c8 , 0x632209 , 0x63224a , 0x63228b , 0x630620 , 0x632f6d , 0x6322d1 , 0x63231f , 0x632365 , 0x6323ab , 0x632411 , 0x632477 , 0x6324bd , 0x6325ad , 0x632613 , 0x632679 , 0x6326df , 0x632720 , 0x632f6d , 0x630557 , 0x62f9a7 , 0x62f1e6 , 0x62fada , 0x62fc3a , 0x62fd8e , 0x6304e8 , 0x630525 , 0x62f6d0 , 0x6305e1 , 0x630652 , 0x6306dc , 0x63071b , 0x6309f6 , 0x630a78 , 0x630afb , 0x630b5c , ---Type to continue, or q to quit--- 0x62f95e , 0x632766 , 0x6327e9 , 0x63282f , 0x632875 , 0x6328bb , 0x632901 , 0x632967 , 0x6329cd , 0x632a33 , 0x632a99 , 0x632bd8 , 0x632c3e , 0x632ca4 , 0x632cea , 0x632d50 , 0x632db6 , 0x632e0a , 0x632e5e , 0x631ce6 , 0x631d33 , 0x632eab , 0x632f0e , 0x632f6d , 0x62fee2 , 0x62ffe8 , 0x63012d , 0x630272 , 0x6303ad , 0x63105d , 0x631534 , 0x631e84 , 0x633140 , 0x6331b6 , 0x632f6d , 0x632f6d , 0x633253 , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x6332db } 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 to continue, or q 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 , 0x632fcd , 0x632fcf , 0x632fd1 , 0x632fd3 , 0x632fd3 , 0x633033 , 0x6330a6 , 0x62f0f0 , 0x62f0f2 , 0x62f0f4 , 0x62f0f6 , 0x62f0f8 , 0x62f0f8 , 0x62f0fe , 0x62f0b3 , 0x62f575 , 0x62f577 , 0x62f579 , 0x62f57b , 0x62f57d , 0x62f57d , 0x62f5be , 0x62f583 , 0x62f776 , 0x62f778 , 0x62f77a , 0x62f77c , 0x62f77e , 0x62f77e , 0x62f71e , 0x62f73b , ---Type to continue, or q to quit--- 0x62f838 , 0x62f83a , 0x62f83c , 0x62f83e , 0x62f840 , 0x62f840 , 0x62f7e0 , 0x62f7fd , 0x62f8fa , 0x62f8fc , 0x62f8fe , 0x62f900 , 0x62f902 , 0x62f902 , 0x62f8a2 , 0x62f8bf , 0x6309b7 , 0x63078c , 0x630783 , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x630bdd , 0x630cb6 , 0x630d14 , 0x630d73 , 0x630dd6 , 0x62f3ef , 0x62f465 , 0x630e4b , 0x62f346 , 0x62f4cb , 0x630eb1 , 0x630f17 , 0x630f5d , 0x630fc3 , 0x631010 , 0x6310dd , 0x631123 , 0x631189 , 0x63120c , 0x631252 , 0x631298 , 0x6312fe , 0x631364 , 0x6313ca , 0x63144d , 0x63149a , 0x6314e7 , 0x6315b4 , 0x631645 , 0x6316d6 , 0x631927 , 0x631992 , 0x6319fd , 0x631a68 , 0x631ad3 , 0x631b20 , 0x631bb2 , 0x631bff , 0x631c4c , 0x631c99 , 0x631d99 , 0x630620 , 0x631df6 , 0x631e3c , 0x631f04 , 0x631f61 , 0x631fbe , 0x632004 , 0x632050 , 0x63209c , 0x6320f0 , 0x632f6d , 0x632146 , 0x632187 , 0x6321c8 , 0x632209 , 0x63224a , 0x63228b , 0x630620 , 0x632f6d , 0x6322d1 , 0x63231f , 0x632365 , 0x6323ab , 0x632411 , 0x632477 , 0x6324bd , 0x6325ad , 0x632613 , 0x632679 , 0x6326df , 0x632720 , 0x632f6d , 0x630557 , 0x62f9a7 , 0x62f1e6 , 0x62fada , 0x62fc3a , 0x62fd8e , 0x6304e8 , 0x630525 , 0x62f6d0 , 0x6305e1 , 0x630652 , 0x6306dc , 0x63071b , 0x6309f6 , 0x630a78 , 0x630afb , 0x630b5c , ---Type to continue, or q to quit--- 0x62f95e , 0x632766 , 0x6327e9 , 0x63282f , 0x632875 , 0x6328bb , 0x632901 , 0x632967 , 0x6329cd , 0x632a33 , 0x632a99 , 0x632bd8 , 0x632c3e , 0x632ca4 , 0x632cea , 0x632d50 , 0x632db6 , 0x632e0a , 0x632e5e , 0x631ce6 , 0x631d33 , 0x632eab , 0x632f0e , 0x632f6d , 0x62fee2 , 0x62ffe8 , 0x63012d , 0x630272 , 0x6303ad , 0x63105d , 0x631534 , 0x631e84 , 0x633140 , 0x6331b6 , 0x632f6d , 0x632f6d , 0x633253 , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x6332db } 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 count = 6 #28 0x00000000005e4a02 in Ffuncall_interactively (nargs=2, args=0x7ffd186d3058) at callint.c:250 ---Type to continue, or q 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 , 0x632fcd , 0x632fcf , 0x632fd1 , 0x632fd3 , 0x632fd3 , 0x633033 , 0x6330a6 , 0x62f0f0 , 0x62f0f2 , ---Type to continue, or q to quit--- 0x62f0f4 , 0x62f0f6 , 0x62f0f8 , 0x62f0f8 , 0x62f0fe , 0x62f0b3 , 0x62f575 , 0x62f577 , 0x62f579 , 0x62f57b , 0x62f57d , 0x62f57d , 0x62f5be , 0x62f583 , 0x62f776 , 0x62f778 , 0x62f77a , 0x62f77c , 0x62f77e , 0x62f77e , 0x62f71e , 0x62f73b , 0x62f838 , 0x62f83a , 0x62f83c , 0x62f83e , 0x62f840 , 0x62f840 , 0x62f7e0 , 0x62f7fd , 0x62f8fa , 0x62f8fc , 0x62f8fe , 0x62f900 , 0x62f902 , 0x62f902 , 0x62f8a2 , 0x62f8bf , 0x6309b7 , 0x63078c , 0x630783 , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x630bdd , 0x630cb6 , 0x630d14 , 0x630d73 , 0x630dd6 , 0x62f3ef , 0x62f465 , 0x630e4b , 0x62f346 , 0x62f4cb , 0x630eb1 , 0x630f17 , 0x630f5d , 0x630fc3 , 0x631010 , 0x6310dd , 0x631123 , 0x631189 , 0x63120c , 0x631252 , 0x631298 , 0x6312fe , 0x631364 , 0x6313ca , 0x63144d , 0x63149a , 0x6314e7 , 0x6315b4 , 0x631645 , 0x6316d6 , 0x631927 , 0x631992 , 0x6319fd , 0x631a68 , 0x631ad3 , 0x631b20 , 0x631bb2 , 0x631bff , 0x631c4c , 0x631c99 , 0x631d99 , 0x630620 , 0x631df6 , 0x631e3c , 0x631f04 , 0x631f61 , 0x631fbe , 0x632004 , 0x632050 , 0x63209c , 0x6320f0 , 0x632f6d , 0x632146 , 0x632187 , 0x6321c8 , 0x632209 , 0x63224a , 0x63228b , 0x630620 , 0x632f6d , 0x6322d1 , 0x63231f , 0x632365 , 0x6323ab , 0x632411 , 0x632477 , 0x6324bd , 0x6325ad , ---Type to continue, or q to quit--- 0x632613 , 0x632679 , 0x6326df , 0x632720 , 0x632f6d , 0x630557 , 0x62f9a7 , 0x62f1e6 , 0x62fada , 0x62fc3a , 0x62fd8e , 0x6304e8 , 0x630525 , 0x62f6d0 , 0x6305e1 , 0x630652 , 0x6306dc , 0x63071b , 0x6309f6 , 0x630a78 , 0x630afb , 0x630b5c , 0x62f95e , 0x632766 , 0x6327e9 , 0x63282f , 0x632875 , 0x6328bb , 0x632901 , 0x632967 , 0x6329cd , 0x632a33 , 0x632a99 , 0x632bd8 , 0x632c3e , 0x632ca4 , 0x632cea , 0x632d50 , 0x632db6 , 0x632e0a , 0x632e5e , 0x631ce6 , 0x631d33 , 0x632eab , 0x632f0e , 0x632f6d , 0x62fee2 , 0x62ffe8 , 0x63012d , 0x630272 , 0x6303ad , 0x63105d , 0x631534 , 0x631e84 , 0x633140 , 0x6331b6 , 0x632f6d , 0x632f6d , 0x633253 , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x632f6d , 0x6332db } count = 3 op = 3 vectorp = 0x9df2d8 stack = { pc = 0xb94e83 "\006\006\071\203\242", byte_string = 10351284, byte_string_start = 0xb94e08 "\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 to continue, or q 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 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 to continue, or q 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 , handlers=18912, hfun=0x551e1c ) 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 , 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 to continue, or q 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 11 08:39:55 2015 Received: (at 21313) by debbugs.gnu.org; 11 Sep 2015 12:39:55 +0000 Received: from localhost ([127.0.0.1]:56248 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaNcQ-0006jF-Up for submit@debbugs.gnu.org; Fri, 11 Sep 2015 08:39:55 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:54872) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaNcO-0006j2-7U for 21313@debbugs.gnu.org; Fri, 11 Sep 2015 08:39:52 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NUI00F00IRWGO00@a-mtaout22.012.net.il> for 21313@debbugs.gnu.org; Fri, 11 Sep 2015 15:39:12 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUI00FZ3J5CBV20@a-mtaout22.012.net.il>; Fri, 11 Sep 2015 15:39:12 +0300 (IDT) Date: Fri, 11 Sep 2015 15:39:05 +0300 From: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event In-reply-to: <87bnd9cf7g.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <831te53zbq.fsf@gnu.org> References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21313 Cc: 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 11 09:06:54 2015 Received: (at 21313) by debbugs.gnu.org; 11 Sep 2015 13:06:54 +0000 Received: from localhost ([127.0.0.1]:56286 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaO2X-0007M9-Rn for submit@debbugs.gnu.org; Fri, 11 Sep 2015 09:06:54 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:40610) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaO2V-0007Ly-Jf for 21313@debbugs.gnu.org; Fri, 11 Sep 2015 09:06:52 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8C91B20A06 for <21313@debbugs.gnu.org>; Fri, 11 Sep 2015 09:06:51 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Fri, 11 Sep 2015 09:06:51 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=VlQ/9WbGKkKwF9sgCR+xOaNxtbY=; b=dGuVq DPFhhH3nRFHM3N0aJDqIboaEHy+WwhIHkBwWcJUfW77wPB1cJvlKI5PdJK9BNc/B ZQf+vy3hg6IbWcfc5890MuTugL6HrWS7Gcvb911BT+ub3akZZfYhPHo0N99nFLGj Qp3TZU3TCT88N8ek49ULwv1V1hBrokwx46Mc7c= X-Sasl-enc: Cwr7tl8gn5jzueEE3VsDnWic6Dqh/a5onwo74aspyS72 1441976811 Received: from thinkpad-t440p (unknown [2.161.110.122]) by mail.messagingengine.com (Postfix) with ESMTPA id E3B9FC00286; Fri, 11 Sep 2015 09:06:50 -0400 (EDT) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> Date: Fri, 11 Sep 2015 15:06:48 +0200 In-Reply-To: <831te53zbq.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 11 Sep 2015 15:39:05 +0300") Message-ID: <871te5cdg7.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21313 Cc: 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 11 09:59:44 2015 Received: (at 21313) by debbugs.gnu.org; 11 Sep 2015 13:59:44 +0000 Received: from localhost ([127.0.0.1]:56987 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaOrf-0000F5-QO for submit@debbugs.gnu.org; Fri, 11 Sep 2015 09:59:44 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:36793) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaOrd-0000Ew-BF for 21313@debbugs.gnu.org; Fri, 11 Sep 2015 09:59:42 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NUI00700MC3KW00@mtaout28.012.net.il> for 21313@debbugs.gnu.org; Fri, 11 Sep 2015 16:59:25 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUI00PW1MV15190@mtaout28.012.net.il>; Fri, 11 Sep 2015 16:59:25 +0300 (IDT) Date: Fri, 11 Sep 2015 16:59:33 +0300 From: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event In-reply-to: <871te5cdg7.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <83wpvx2h16.fsf@gnu.org> References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21313 Cc: 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 15 11:37:06 2015 Received: (at 21313) by debbugs.gnu.org; 15 Sep 2015 15:37:06 +0000 Received: from localhost ([127.0.0.1]:33447 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbsI5-00028K-I9 for submit@debbugs.gnu.org; Tue, 15 Sep 2015 11:37:05 -0400 Received: from deliver.uni-koblenz.de ([141.26.64.15]:50591) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbsI3-000287-3T for 21313@debbugs.gnu.org; Tue, 15 Sep 2015 11:37:04 -0400 Received: from thinkpad-t440p (dhcp23.uni-koblenz.de [141.26.71.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id E25A71A82D6; Tue, 15 Sep 2015 17:37:02 +0200 (CEST) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> Date: Tue, 15 Sep 2015 17:37:02 +0200 Message-ID: <87r3lziti9.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 21313 Cc: 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) Eli Zaretskii 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 15 12:01:45 2015 Received: (at 21313) by debbugs.gnu.org; 15 Sep 2015 16:01:45 +0000 Received: from localhost ([127.0.0.1]:33468 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zbsfx-00031E-2Z for submit@debbugs.gnu.org; Tue, 15 Sep 2015 12:01:45 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:53924) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zbsfv-000313-1m for 21313@debbugs.gnu.org; Tue, 15 Sep 2015 12:01:43 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NUQ00I0071V5900@a-mtaout20.012.net.il> for 21313@debbugs.gnu.org; Tue, 15 Sep 2015 19:01:41 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUQ00IMG76S1C40@a-mtaout20.012.net.il>; Tue, 15 Sep 2015 19:01:41 +0300 (IDT) Date: Tue, 15 Sep 2015 19:01:42 +0300 From: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event In-reply-to: <87r3lziti9.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <83zj0n7jtl.fsf@gnu.org> References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21313 Cc: 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 16 07:39:16 2015 Received: (at 21313) by debbugs.gnu.org; 16 Sep 2015 11:39:16 +0000 Received: from localhost ([127.0.0.1]:34200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZcB3T-0002Fw-Md for submit@debbugs.gnu.org; Wed, 16 Sep 2015 07:39:15 -0400 Received: from deliver.uni-koblenz.de ([141.26.64.15]:56583) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZcB3Q-0002Fn-Sk for 21313@debbugs.gnu.org; Wed, 16 Sep 2015 07:39:14 -0400 Received: from thinkpad-t440p (wlan-95-207.uni-koblenz.de [141.26.95.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id 1CC2C1A8323; Wed, 16 Sep 2015 13:39:12 +0200 (CEST) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> Date: Wed, 16 Sep 2015 13:39:11 +0200 In-Reply-To: <83zj0n7jtl.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 15 Sep 2015 19:01:42 +0300") Message-ID: <87oah2sie8.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 21313 Cc: Jan =?utf-8?Q?Dj=C3=A4rv?= , 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) Eli Zaretskii writes: >> From: Tassilo Horn >> 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 22 01:49:15 2015 Received: (at 21313-done) by debbugs.gnu.org; 22 Sep 2015 05:49:15 +0000 Received: from localhost ([127.0.0.1]:41119 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZeGS2-0001VA-OA for submit@debbugs.gnu.org; Tue, 22 Sep 2015 01:49:15 -0400 Received: from deliver.uni-koblenz.de ([141.26.64.15]:44240) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZeGS0-0001Us-4X for 21313-done@debbugs.gnu.org; Tue, 22 Sep 2015 01:49:13 -0400 Received: from thinkpad-t440p (dhcp207.uni-koblenz.de [141.26.71.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id 4B5981A8393; Tue, 22 Sep 2015 07:49:10 +0200 (CEST) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> Date: Tue, 22 Sep 2015 07:49:09 +0200 In-Reply-To: <83zj0n7jtl.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 15 Sep 2015 19:01:42 +0300") Message-ID: <87wpvjovfu.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 21313-done Cc: 21313-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) Eli Zaretskii 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 22 04:01:04 2015 Received: (at 21313) by debbugs.gnu.org; 22 Sep 2015 08:01:04 +0000 Received: from localhost ([127.0.0.1]:41200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZeIVb-0006pc-Mv for submit@debbugs.gnu.org; Tue, 22 Sep 2015 04:01:03 -0400 Received: from mail-wi0-f169.google.com ([209.85.212.169]:35357) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZeIVa-0006pG-EG for 21313@debbugs.gnu.org; Tue, 22 Sep 2015 04:01:03 -0400 Received: by wicge5 with SMTP id ge5so148790900wic.0 for <21313@debbugs.gnu.org>; Tue, 22 Sep 2015 01:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:gmane-reply-to-list:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=DR799I98sP2z3kspIQHbl0b1yX+E3I91Anv2dGp/s8I=; b=GSdlKWphXydQa5vyceUQGoGPcFoCNRarnr0aMB5hcIzA4hlslOPV1wNv04EMsiTjjZ Vg/Ko7W6b+G43Nun93sJATclhKDuw9B46eeAmkjaULS6NnbjvKGLVIIPDy4H+14dWY8j DB4e1nnDh/h692yMHV/2EccHll/n+oHyMjA+wZeE92E985+5dQXM9rfHrrNmMu+5awl8 BxLhj0swXmEnfG/A4vvpUpLUAgcur/mYJsIELIPgZYS3e/W/rYCs6+W9Ew6RbgU8UCEK IVITddG/pK4uMNhNRful3Vry6nQkFNfuaw+aAhvAD8zfU122o2bN0rkZ8/1g4p8e5jww /PgA== X-Received: by 10.194.93.35 with SMTP id cr3mr27203408wjb.46.1442908861689; Tue, 22 Sep 2015 01:01:01 -0700 (PDT) Received: from rpluim-ubuntu ([213.30.189.66]) by smtp.gmail.com with ESMTPSA id wc12sm1676582wic.18.2015.09.22.01.01.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Sep 2015 01:01:00 -0700 (PDT) From: Robert Pluim To: 21313@debbugs.gnu.org Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> X-Debbugs-No-Ack: yes Gmane-Reply-To-List: yes Date: Tue, 22 Sep 2015 10:00:59 +0200 In-Reply-To: <87wpvjovfu.fsf@gnu.org> (Tassilo Horn's message of "Tue, 22 Sep 2015 07:49:09 +0200") Message-ID: <877fnikhms.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21313 Cc: tsdh@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Tassilo Horn writes: > Eli Zaretskii 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 22 04:21:16 2015 Received: (at 21313) by debbugs.gnu.org; 22 Sep 2015 08:21:16 +0000 Received: from localhost ([127.0.0.1]:41219 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZeIpA-0007aQ-Al for submit@debbugs.gnu.org; Tue, 22 Sep 2015 04:21:16 -0400 Received: from deliver.uni-koblenz.de ([141.26.64.15]:56600) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZeIp8-0007a8-9p for 21313@debbugs.gnu.org; Tue, 22 Sep 2015 04:21:15 -0400 Received: from thinkpad-t440p (dhcp199.uni-koblenz.de [141.26.71.199]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id 4CC103D6004; Tue, 22 Sep 2015 10:21:12 +0200 (CEST) From: Tassilo Horn To: Robert Pluim Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> Date: Tue, 22 Sep 2015 10:21:11 +0200 In-Reply-To: <877fnikhms.fsf@gmail.com> (Robert Pluim's message of "Tue, 22 Sep 2015 10:00:59 +0200") Message-ID: <87oaguq2yw.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 21313 Cc: 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) Robert Pluim 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 From unknown Mon Jun 23 07:49:16 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: Did not alter fixed versions and reopened. Date: Fri, 02 Oct 2015 18:21:01 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # Did not alter fixed versions and reopened. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 02 14:36:24 2015 Received: (at 21313) by debbugs.gnu.org; 2 Oct 2015 18:36:24 +0000 Received: from localhost ([127.0.0.1]:52401 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zi5Bw-0006cA-5m for submit@debbugs.gnu.org; Fri, 02 Oct 2015 14:36:24 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:59775) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zi5Bu-0006c3-EC for 21313@debbugs.gnu.org; Fri, 02 Oct 2015 14:36:23 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 4156B20697 for <21313@debbugs.gnu.org>; Fri, 2 Oct 2015 14:36:22 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Fri, 02 Oct 2015 14:36:22 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=2egY43WpD3ZCrU9G4AvFnD2263w=; b=WYGr/ HFQ7wptkpZmZJTkLZFH5pH8adX06XIVilqlRXtejj/OH7gqUZXieiWp16hXXIOxD yE5qL3lg9V9iJstw6EbLk95Jw/l+V9e2FbYNRXwM/C97jWOsh9d2oWdU7Zspf5ux b2FfU3SC3eU+uotcsN4m0Q1Iow5DbLdEl+h55Y= X-Sasl-enc: M1Kn4yYHexIzHjDa/gu2meo76LBqN4HIgncAhxo4HTq0 1443810981 Received: from thinkpad-t440p (unknown [2.161.209.103]) by mail.messagingengine.com (Postfix) with ESMTPA id 124B1680123; Fri, 2 Oct 2015 14:36:20 -0400 (EDT) From: Tassilo Horn To: Robert Pluim , Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> Date: Fri, 02 Oct 2015 20:36:18 +0200 In-Reply-To: <87oaguq2yw.fsf@gnu.org> (Tassilo Horn's message of "Tue, 22 Sep 2015 10:21:11 +0200") Message-ID: <8737xtt8wt.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21313 Cc: 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 02 15:05:26 2015 Received: (at 21313) by debbugs.gnu.org; 2 Oct 2015 19:05:26 +0000 Received: from localhost ([127.0.0.1]:52426 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zi5e1-0007HM-Bz for submit@debbugs.gnu.org; Fri, 02 Oct 2015 15:05:26 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:33816) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zi5dy-0007HD-RF for 21313@debbugs.gnu.org; Fri, 02 Oct 2015 15:05:24 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NVL00B00WGTN800@a-mtaout21.012.net.il> for 21313@debbugs.gnu.org; Fri, 02 Oct 2015 22:05:21 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NVL00BUDX0WL280@a-mtaout21.012.net.il>; Fri, 02 Oct 2015 22:05:21 +0300 (IDT) Date: Fri, 02 Oct 2015 22:05:14 +0300 From: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event In-reply-to: <8737xtt8wt.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <834mi95bx1.fsf@gnu.org> References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21313 Cc: rpluim@gmail.com, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 02 16:33:15 2015 Received: (at 21313) by debbugs.gnu.org; 2 Oct 2015 20:33:15 +0000 Received: from localhost ([127.0.0.1]:52475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zi711-0002Pe-4H for submit@debbugs.gnu.org; Fri, 02 Oct 2015 16:33:15 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:40271) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zi70y-0002PV-RU for 21313@debbugs.gnu.org; Fri, 02 Oct 2015 16:33:14 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id E63EF201E8 for <21313@debbugs.gnu.org>; Fri, 2 Oct 2015 16:33:10 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Fri, 02 Oct 2015 16:33:10 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=2y8Jrx0r8CnJVbrtOM8APZX6pj8=; b=XJ3Ck VpM0oF/kruj7+bFFASauFuTGURRIXUzLMedMNNuMlSSmBkDvhVdT+rnXHXBGCQm1 O2HpZC9U+XopRNXf5HfyAAD97KScYPpQnKvRNsXvQYe+EcZ+U8JRmZsOO/w4ohkj fjZoLNP2Ump3f5EgbFvYVneJpu6xWfCuGBRZ14= X-Sasl-enc: qQPCtaMsZOC2I6FNEuGtlTqqsWKXz25FJdjO6bFxpfEC 1443817990 Received: from thinkpad-t440p (unknown [2.161.209.103]) by mail.messagingengine.com (Postfix) with ESMTPA id 25EEF6800ED; Fri, 2 Oct 2015 16:33:10 -0400 (EDT) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> Date: Fri, 02 Oct 2015 22:33:08 +0200 In-Reply-To: <834mi95bx1.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 02 Oct 2015 22:05:14 +0300") Message-ID: <87twq9roxn.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21313 Cc: rpluim@gmail.com, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii 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] [next-line] C-k [kill-line] ... but I've never pressed . 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 02 17:10:52 2015 Received: (at 21313) by debbugs.gnu.org; 2 Oct 2015 21:10:52 +0000 Received: from localhost ([127.0.0.1]:52488 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zi7bP-0003Ek-Cc for submit@debbugs.gnu.org; Fri, 02 Oct 2015 17:10:51 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:40255) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zi7bN-0003Eb-8u for 21313@debbugs.gnu.org; Fri, 02 Oct 2015 17:10:50 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NVM00M002JMKU00@a-mtaout22.012.net.il> for 21313@debbugs.gnu.org; Sat, 03 Oct 2015 00:10:47 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NVM00MSA2TUBC90@a-mtaout22.012.net.il>; Sat, 03 Oct 2015 00:10:43 +0300 (IDT) Date: Sat, 03 Oct 2015 00:10:36 +0300 From: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event In-reply-to: <87twq9roxn.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <83wpv53rjn.fsf@gnu.org> References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21313 Cc: rpluim@gmail.com, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 02 17:26:41 2015 Received: (at 21313) by debbugs.gnu.org; 2 Oct 2015 21:26:41 +0000 Received: from localhost ([127.0.0.1]:52519 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zi7qi-0003bX-O0 for submit@debbugs.gnu.org; Fri, 02 Oct 2015 17:26:40 -0400 Received: from mout.gmx.net ([212.227.17.20]:55150) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zi7qh-0003bP-0z for 21313@debbugs.gnu.org; Fri, 02 Oct 2015 17:26:39 -0400 Received: from detlef.gmx.de ([87.146.40.216]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lt1yI-1aejmo30bC-012ZKQ; Fri, 02 Oct 2015 23:26:36 +0200 From: Michael Albinus To: Tassilo Horn Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> Date: Fri, 02 Oct 2015 23:26:35 +0200 In-Reply-To: <83wpv53rjn.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 03 Oct 2015 00:10:36 +0300") Message-ID: <87h9m9rmgk.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:t5F+lfHfEi0PnbEy9PU1AyU4/odsUg0pvksXUauCiQrRk0072Fx WMcPMzbjQOMIUj+VKcys9MkStXGl3DikPYMEk9ayVjFLMT9qGXY9HTfl0tAjbj5OLRMGloc hlBVAzm9HCMc3wsL5J2Js3KYCsPCCcDMpoXtNhaTBASP3oWqx0szyCGyB+AWUYkWrBsZcDw pNiIJSLoQ9Okf3UogrETg== X-UI-Out-Filterresults: notjunk:1;V01:K0:p+hpa6aBpXc=:IhGT0d97f3xd1ejeOUXqc3 zMx+oUVpRfErp6CuongawLFEQ54LV/Le0YilqVtiu4whjJxcv54QorXmBu8KkZ2Oq4oEi+kwI bN/v5VL3hEG2Qr9UToY6muahUm86sQnqnc7KVDKxgVIep+1Xqf+sVI7JiVEMrFXdvwQmyX/aU nplTsW3ZNahlBjpsGMBTsNtI1uLWo1oNaRIFnSpscnPyvwxLfdd1hlH4TscNvEEdXW9xipQhu g/riA5vK4jjbTtanbFu6Ltyb/QC8/cx15fLdao5jAvbufFF21JzTkE4mOtFVoHwyyFHJiSvJK 4VnM2Jgkatb5wMCypeZ6ibrfBTgAnVBNL+mbxUrp65n344m14wCFzVLwOvQq9EHn0QtrcM7e1 jv4p65gImF/5+EUb00OGQq6CUCCYGvF6zHoVwWs2vs6RI0BXn6Vr9cqlCIdHsSnOdCD30dmDa wfDsrXiyEtjfre/cKxBX/m+pe56QXZKuE/ePrwgsrNAAbdgxJEWcfWSna352S/SHMBP1Pk9zt IsFejTUt3UJrTjUVnro5r3IC/iMqGIw1OJe6n+CPNZ9+gMXMRJ8G+GmlxH7ZBps0he5Bdkzkv 4qO3h7ezL6BHp749JaoMZmfpcNuj8H7IEGUg11bqkkzVa/Ij1sxMxsbGIzsiePytJG5Aia1uB sblWZ2Mnr5PRHOZAyc3FIQFbfZnwx5syrf39T6mCW8nmf/kdZdbPlNjvU/dNhYGzbQqjNmSCH 7xORKFI41XJVGtmnZKOVT0nuVb/C4kVyyEmUbMDs7UIqKYPPMPxoy9jJwhjKB9g8JCJ72S0E/ B3gRZ1u X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21313 Cc: Eli Zaretskii , rpluim@gmail.com, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 03 01:40:13 2015 Received: (at 21313) by debbugs.gnu.org; 3 Oct 2015 05:40:13 +0000 Received: from localhost ([127.0.0.1]:52673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiFYK-0006jB-Qo for submit@debbugs.gnu.org; Sat, 03 Oct 2015 01:40:13 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:41977) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiFYI-0006j2-45 for 21313@debbugs.gnu.org; Sat, 03 Oct 2015 01:40:11 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6AE6A205FE for <21313@debbugs.gnu.org>; Sat, 3 Oct 2015 01:40:09 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Sat, 03 Oct 2015 01:40:09 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:references:subject:to:x-sasl-enc:x-sasl-enc; s= smtpout; bh=aXkD1TK+g2qL8j11TgT7whNDZx0=; b=MYYKLboOhv1X43CGmxJ7 hyHEXONU7uxLV7htUQfalc5J3uxSQWVxsE3DN4wiOXPSRrRqoE7gRBPQZBr9uIbV pWODXpjI3cKdbDoNKmxzrrqcXbziT96lIGhWw1hRABhM/3NxTB9h9MepgYn9bR3M Hc5VRO1GpFkmX5lWc4sCB7k= X-Sasl-enc: eFezPK0uENQG+pEtRaOTrToQxjqJ2YKHRB+a515qYo/1 1443850808 Received: from thinkpad-t440p (unknown [2.160.114.254]) by mail.messagingengine.com (Postfix) with ESMTPA id E8AC8C00018; Sat, 3 Oct 2015 01:40:07 -0400 (EDT) From: Tassilo Horn To: Michael Albinus Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> Date: Sat, 03 Oct 2015 07:40:05 +0200 Message-ID: <87wpv4qzm2.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21313 Cc: Eli Zaretskii , rpluim@gmail.com, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Michael Albinus 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 03 02:33:08 2015 Received: (at 21313) by debbugs.gnu.org; 3 Oct 2015 06:33:08 +0000 Received: from localhost ([127.0.0.1]:52696 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiGNY-0007yc-H2 for submit@debbugs.gnu.org; Sat, 03 Oct 2015 02:33:08 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:39605) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiGNX-0007yU-5b for 21313@debbugs.gnu.org; Sat, 03 Oct 2015 02:33:07 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id EC33E20126 for <21313@debbugs.gnu.org>; Sat, 3 Oct 2015 02:33:06 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 03 Oct 2015 02:33:06 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=Ce1yFP63gBTjcjQnNCEaGnoArTQ=; b=E+ZD+ C6IRHSKhusaIaJyC0R6phLb8VIt3I5/lxIeOzp517wKQfGwWs1M+iTKHCHUtByK5 OdrG6OEYxqlwqwzpJU2dJn2WRgsKjV2DqcDTNWdRx27RsaQWlabH4Zos76PbC2ng FMzBUFnoBgJ56JSOsVM5hduhan71IB6RJFLUgE= X-Sasl-enc: edBTYNLFbmAe0WvWfXlMmNOxTcODJ3ulfCR2ukyYEDk4 1443853986 Received: from thinkpad-t440p (unknown [2.160.114.254]) by mail.messagingengine.com (Postfix) with ESMTPA id AE6AAC00013; Sat, 3 Oct 2015 02:33:02 -0400 (EDT) From: Tassilo Horn To: Michael Albinus Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> Date: Sat, 03 Oct 2015 08:32:56 +0200 In-Reply-To: <87wpv4qzm2.fsf@gnu.org> (Tassilo Horn's message of "Sat, 03 Oct 2015 07:40:05 +0200") Message-ID: <877fn4ihrb.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21313 Cc: Eli Zaretskii , rpluim@gmail.com, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Tassilo Horn 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 03 03:14:35 2015 Received: (at 21313) by debbugs.gnu.org; 3 Oct 2015 07:14:35 +0000 Received: from localhost ([127.0.0.1]:52716 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiH1e-0000UB-Nj for submit@debbugs.gnu.org; Sat, 03 Oct 2015 03:14:34 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:58178) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiH1b-0000U0-SK for 21313@debbugs.gnu.org; Sat, 03 Oct 2015 03:14:33 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NVM00D00UHY8000@a-mtaout21.012.net.il> for 21313@debbugs.gnu.org; Sat, 03 Oct 2015 10:14:30 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NVM00DXGUS66I60@a-mtaout21.012.net.il>; Sat, 03 Oct 2015 10:14:30 +0300 (IDT) Date: Sat, 03 Oct 2015 10:14:24 +0300 From: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event In-reply-to: <877fn4ihrb.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <83twq84e5r.fsf@gnu.org> References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <877fn4ihrb.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21313 Cc: rpluim@gmail.com, michael.albinus@gmx.de, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > Cc: Eli Zaretskii , 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.) From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 03 03:43:43 2015 Received: (at 21313) by debbugs.gnu.org; 3 Oct 2015 07:43:43 +0000 Received: from localhost ([127.0.0.1]:52721 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiHTk-0001Co-BG for submit@debbugs.gnu.org; Sat, 03 Oct 2015 03:43:43 -0400 Received: from mout.gmx.net ([212.227.17.22]:50942) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiHTh-0001Ce-Ci for 21313@debbugs.gnu.org; Sat, 03 Oct 2015 03:43:34 -0400 Received: from detlef.gmx.de ([79.195.0.223]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M82zV-1ad9OM3l4r-00vg37; Sat, 03 Oct 2015 09:43:32 +0200 From: Michael Albinus To: Tassilo Horn Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> Date: Sat, 03 Oct 2015 09:43:30 +0200 Message-ID: <87a8s0v1lp.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:POiTJBzIih+a/qSa/RZobfDeMOpb+XEAI89IAvCagenaLRnINbq 2qRVrHwLazjxuY2JuPhzApVgld4sPpb92qcBDHGgS6Czf/gYnwD/qYWiQlAxfvDD46jrxbF HASWu5zVFBFMrP8/KBQCReGzi79Lz0tm/P7DH5JuENFAq9f1OnwYaQucHjQaMBkHtJB9Z5x eZULOHZHbMvUXC3/wK5lw== X-UI-Out-Filterresults: notjunk:1;V01:K0:PDYSHeqFigU=:67AG55fT3LsPWomRjDd3yQ TLeEWNzPzK6layFyXDU8cl1WYP0VLrFgWaK6VfHqgVP48Geev4Cmvaiu8Y5WZKHKTwjoD5F3E jPNmIlJBWEX0RWhQe1JYjutvIsxdTRp2N4WyHoxw7jnQJCqq8V9UAThoIFWSrygNliaSerXMc 0HBjlH+3+8PW6WUtAVYyF+MP/o6sDSelo4oy7njgP5wpVeZDmsN+kVycMW93Y0IzdbXITOMTX c9hrkWDsQJ4Ch8KGJEDLCIkHKUtAtprcyNWC7Iq2BYkdytQ+QvA/7m/AlrinbRE51jEzBt/09 ccBKQewz+FomDg3+H2seeS7PLO/HwsemR7LZwQuvrXOGsScRP0Tv+ac+7VWvt1EeqgLBZG9tn JTaVHUZ15E18+UeNN7YFSgiqdpszaDIWmGe07Z1/WU48JLd04Y5pGhblZx6AAEUex+Me3Xvk2 Rr6rVRdInIdiXEuP5BSIzk35rLBM4PZGTgQWARj1iWOrMA1yRh0I8Hx48C7PsC4YtxobPvSe6 5phjSlEFhKPt9lG2h3GB63EuDC3qZ5Fgeogj2Nqo1oLUumjtKQRFuQnFnJ332cK39asXx/Fod 5d8bcHIKKfNqE47fibnz6acxonWdON/7TfPKBmAcjTsPLJ3uqI+3o9zxqBYpur+dd2+7xm9nM GBKFPD1Cjp9ohoHyDvBnMoewJIo4u1BtQkbqkq/3KmF/CAU6zrFJ2+8ID/EKzQT8kucn3Qb/A EQAuPmwxKeroOILPeHKIg53h+IEES3aPVcIwrM8SlN2vOreLgrzTfk9hNiWuRl/h587U6At/o pu0+AFd X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21313 Cc: Eli Zaretskii , rpluim@gmail.com, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Tassilo Horn 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 03 04:11:04 2015 Received: (at 21313) by debbugs.gnu.org; 3 Oct 2015 08:11:04 +0000 Received: from localhost ([127.0.0.1]:52729 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiHuK-0001qM-8Z for submit@debbugs.gnu.org; Sat, 03 Oct 2015 04:11:04 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:50380) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiHuI-0001qF-KJ for 21313@debbugs.gnu.org; Sat, 03 Oct 2015 04:11:03 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 5394D2070C for <21313@debbugs.gnu.org>; Sat, 3 Oct 2015 04:11:02 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sat, 03 Oct 2015 04:11:02 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=KeH9CCG4VqH5+9RkhoS95H3jjw8=; b=scx8a Nb7MpQRpu7aVh7Bc8aRiAScMqViz7yPUVzhOYf9cy6K2uGC+pOEdlQMpJMB2OlG/ Ucx28nA4+CGhwgoaZdGOMrj69g0S0rNpq4R9jfC4slkQffcbtzmuGJEseV+Jju1c RKZfk3/QlD6uTtRxDdX8Kg2Ooy183PoPdY56u8= X-Sasl-enc: X8TgqYCnPQdqMcZLOgVMsM7CG9PHei6zJ78cUKIlS8+S 1443859861 Received: from thinkpad-t440p (unknown [2.160.114.254]) by mail.messagingengine.com (Postfix) with ESMTPA id 10D266801B4; Sat, 3 Oct 2015 04:11:00 -0400 (EDT) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <877fn4ihrb.fsf@gnu.org> <83twq84e5r.fsf@gnu.org> Date: Sat, 03 Oct 2015 10:10:58 +0200 In-Reply-To: <83twq84e5r.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 03 Oct 2015 10:14:24 +0300") Message-ID: <87y4fkgynh.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21313 Cc: rpluim@gmail.com, michael.albinus@gmx.de, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 03 04:13:10 2015 Received: (at 21313) by debbugs.gnu.org; 3 Oct 2015 08:13:10 +0000 Received: from localhost ([127.0.0.1]:52733 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiHwM-0001tn-1c for submit@debbugs.gnu.org; Sat, 03 Oct 2015 04:13:10 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:44844) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiHwJ-0001tf-Go for 21313@debbugs.gnu.org; Sat, 03 Oct 2015 04:13:07 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 724072014A for <21313@debbugs.gnu.org>; Sat, 3 Oct 2015 04:13:07 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Sat, 03 Oct 2015 04:13:07 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=pPBIAKSpOi/pdu5hS9IA5Z2PYWY=; b=cyteV nTGSfQgydJW3THTz+HyAXeA0Dl5ATKYK1r35RcjxA9vsU6snqoUEKA6aSheY8Ilx 1y51BTZtbheAX871Vk/r93Gk7EiawH2UkHKn8CDJ+d4uasApRPJhwu1jrVV73ISa 8Vd5qa1M9yMOMTvfwF911LP5IbsFtum6QHMtgk= X-Sasl-enc: 8ctyczfBpgUwTN4Cx/gxvCDMzJYrhEy3mqVr/M7tUiw+ 1443859986 Received: from thinkpad-t440p (unknown [2.160.114.254]) by mail.messagingengine.com (Postfix) with ESMTPA id 150F9680166; Sat, 3 Oct 2015 04:13:05 -0400 (EDT) From: Tassilo Horn To: Michael Albinus Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <87a8s0v1lp.fsf@gmx.de> Date: Sat, 03 Oct 2015 10:13:03 +0200 In-Reply-To: <87a8s0v1lp.fsf@gmx.de> (Michael Albinus's message of "Sat, 03 Oct 2015 09:43:30 +0200") Message-ID: <87twq8gyk0.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21313 Cc: Eli Zaretskii , rpluim@gmail.com, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Michael Albinus 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 03 05:38:48 2015 Received: (at 21313) by debbugs.gnu.org; 3 Oct 2015 09:38:48 +0000 Received: from localhost ([127.0.0.1]:52764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiJHE-0003st-Ao for submit@debbugs.gnu.org; Sat, 03 Oct 2015 05:38:48 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:60155) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiJHB-0003sk-LD for 21313@debbugs.gnu.org; Sat, 03 Oct 2015 05:38:47 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id C1E302023F for <21313@debbugs.gnu.org>; Sat, 3 Oct 2015 05:38:43 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Sat, 03 Oct 2015 05:38:43 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:references:subject:to:x-sasl-enc:x-sasl-enc; s= smtpout; bh=HAPYKMLMD5qM7n9RtjHJicy+nro=; b=GsFIKNQnM72Y30wY1IGr ztT11ZCTjSfRsjOLtTOYPqZpRkiExdgSvosmxpGfO0Z/c6oSDzMuM81Q9Er4L0UW SmPy5XSIr5Gv6VMK50DqJsBBE8qcEmzNhyaNFV1KJk8qaJxZtCHMCVL03BiJ+kFl eUFw8ljjJ/k7WC3b/llt0Q4= X-Sasl-enc: B4hfigpFL8pggpuiXE5GbNdJkTlT0DUgn/IBGPghoqRJ 1443865123 Received: from thinkpad-t440p (unknown [2.160.114.254]) by mail.messagingengine.com (Postfix) with ESMTPA id CF3F2680194; Sat, 3 Oct 2015 05:38:42 -0400 (EDT) From: Tassilo Horn To: Michael Albinus Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <87a8s0v1lp.fsf@gmx.de> <87twq8gyk0.fsf@gnu.org> Date: Sat, 03 Oct 2015 11:38:40 +0200 Message-ID: <87lhbk47hb.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21313 Cc: 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Tassilo Horn 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 03 05:53:29 2015 Received: (at 21313) by debbugs.gnu.org; 3 Oct 2015 09:53:29 +0000 Received: from localhost ([127.0.0.1]:52784 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiJVQ-0004EI-Tx for submit@debbugs.gnu.org; Sat, 03 Oct 2015 05:53:29 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:63498) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiJVO-0004E8-FV for 21313@debbugs.gnu.org; Sat, 03 Oct 2015 05:53:27 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NVN00I001N6EW00@a-mtaout20.012.net.il> for 21313@debbugs.gnu.org; Sat, 03 Oct 2015 12:53:24 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NVN00I712502290@a-mtaout20.012.net.il>; Sat, 03 Oct 2015 12:53:24 +0300 (IDT) Date: Sat, 03 Oct 2015 12:53:18 +0300 From: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event In-reply-to: <87y4fkgynh.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <83k2r446sx.fsf@gnu.org> References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <877fn4ihrb.fsf@gnu.org> <83twq84e5r.fsf@gnu.org> <87y4fkgynh.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21313 Cc: rpluim@gmail.com, michael.albinus@gmx.de, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 03 06:53:24 2015 Received: (at 21313) by debbugs.gnu.org; 3 Oct 2015 10:53:24 +0000 Received: from localhost ([127.0.0.1]:52842 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiKRQ-0005h1-3Z for submit@debbugs.gnu.org; Sat, 03 Oct 2015 06:53:24 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:54134) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiKRN-0005gs-3x for 21313@debbugs.gnu.org; Sat, 03 Oct 2015 06:53:21 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NVN009003U0DE00@mtaout24.012.net.il> for 21313@debbugs.gnu.org; Sat, 03 Oct 2015 13:46:15 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NVN0020Q4L3VC40@mtaout24.012.net.il>; Sat, 03 Oct 2015 13:46:15 +0300 (IDT) Date: Sat, 03 Oct 2015 13:53:09 +0300 From: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event In-reply-to: <87lhbk47hb.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <83d1ww4416.fsf@gnu.org> References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <87a8s0v1lp.fsf@gmx.de> <87twq8gyk0.fsf@gnu.org> <87lhbk47hb.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21313 Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 03 08:07:03 2015 Received: (at 21313) by debbugs.gnu.org; 3 Oct 2015 12:07:03 +0000 Received: from localhost ([127.0.0.1]:52884 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiLag-0000Y6-LY for submit@debbugs.gnu.org; Sat, 03 Oct 2015 08:07:03 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:49346) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZiLae-0000Xg-DM for 21313@debbugs.gnu.org; Sat, 03 Oct 2015 08:07:01 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E98BB20BE1 for <21313@debbugs.gnu.org>; Sat, 3 Oct 2015 08:06:59 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Sat, 03 Oct 2015 08:06:59 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=3B4DRK1ARfJjun7ooLRPF8jpw/M=; b=hPclS zo9Bu5XlzyEtJCvNztrfTxqhgRCq7VuN7peHOd1eAbkfmGRvNolmKQcIn0Bako1v 84eHAMHQWVRp2wVHTKQggGNzL6FgksnWb7iF426BImqmIS1cESPlHVJGeI6eyjA+ CdYlZH0KSVoydx0Wb/590AHPaQGg/qRZ4ENyn8= X-Sasl-enc: SBjNE7t3FOFOMhyDLJF4A1baKvUHaF9U02k+omC8z8Eg 1443874019 Received: from thinkpad-t440p (unknown [2.160.114.254]) by mail.messagingengine.com (Postfix) with ESMTPA id C4969C00016; Sat, 3 Oct 2015 08:06:58 -0400 (EDT) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <877fn4ihrb.fsf@gnu.org> <83twq84e5r.fsf@gnu.org> <87y4fkgynh.fsf@gnu.org> <83k2r446sx.fsf@gnu.org> Date: Sat, 03 Oct 2015 14:06:56 +0200 In-Reply-To: <83k2r446sx.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 03 Oct 2015 12:53:18 +0300") Message-ID: <87y4fk5f6n.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21313 Cc: rpluim@gmail.com, michael.albinus@gmx.de, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 14 05:58:39 2015 Received: (at 21313) by debbugs.gnu.org; 14 Oct 2015 09:58:39 +0000 Received: from localhost ([127.0.0.1]:39490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZmIpT-0001L3-H6 for submit@debbugs.gnu.org; Wed, 14 Oct 2015 05:58:39 -0400 Received: from nsmtp.uni-koblenz.de ([141.26.64.14]:52094) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZmIpR-0001Ku-A0 for 21313@debbugs.gnu.org; Wed, 14 Oct 2015 05:58:38 -0400 Received: from localhost (localhost [127.0.0.1]) by nsmtp.uni-koblenz.de (Postfix) with ESMTP id F2D40239F09; Wed, 14 Oct 2015 11:58:35 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at uni-koblenz.de Received: from nsmtp.uni-koblenz.de ([127.0.0.1]) by localhost (nsmtp.uni-koblenz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a56wQ7CeDytF; Wed, 14 Oct 2015 11:58:35 +0200 (CEST) Received: from deliver.uni-koblenz.de (deliver.uni-koblenz.de [141.26.64.15]) by nsmtp.uni-koblenz.de (Postfix) with ESMTPS; Wed, 14 Oct 2015 11:58:35 +0200 (CEST) Received: from thinkpad-t440p (dhcp66.uni-koblenz.de [141.26.71.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id A004E1A82D9; Wed, 14 Oct 2015 11:58:35 +0200 (CEST) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <87a8s0v1lp.fsf@gmx.de> <87twq8gyk0.fsf@gnu.org> <87lhbk47hb.fsf@gnu.org> <83d1ww4416.fsf@gnu.org> Date: Wed, 14 Oct 2015 11:58:35 +0200 In-Reply-To: <83d1ww4416.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 03 Oct 2015 13:53:09 +0300") Message-ID: <878u75rctw.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 21313 Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) Eli Zaretskii 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 14 13:05:11 2015 Received: (at 21313) by debbugs.gnu.org; 14 Oct 2015 17:05:11 +0000 Received: from localhost ([127.0.0.1]:51068 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZmPUF-0000qq-2R for submit@debbugs.gnu.org; Wed, 14 Oct 2015 13:05:11 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:49512) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZmPUC-0000qh-PT for 21313@debbugs.gnu.org; Wed, 14 Oct 2015 13:05:10 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NW700000YW1QW00@mtaout25.012.net.il> for 21313@debbugs.gnu.org; Wed, 14 Oct 2015 20:02:40 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NW700O1PZCFLB30@mtaout25.012.net.il>; Wed, 14 Oct 2015 20:02:40 +0300 (IDT) Date: Wed, 14 Oct 2015 20:05:07 +0300 From: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event In-reply-to: <878u75rctw.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <836129xtx8.fsf@gnu.org> References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <87a8s0v1lp.fsf@gmx.de> <87twq8gyk0.fsf@gnu.org> <87lhbk47hb.fsf@gnu.org> <83d1ww4416.fsf@gnu.org> <878u75rctw.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21313 Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 14 15:37:24 2015 Received: (at 21313) by debbugs.gnu.org; 14 Oct 2015 19:37:24 +0000 Received: from localhost ([127.0.0.1]:51155 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZmRrX-0004f1-Of for submit@debbugs.gnu.org; Wed, 14 Oct 2015 15:37:24 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:59789) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZmRrU-0004eq-W3 for 21313@debbugs.gnu.org; Wed, 14 Oct 2015 15:37:22 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 7A8D720A33 for <21313@debbugs.gnu.org>; Wed, 14 Oct 2015 15:37:20 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 14 Oct 2015 15:37:20 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:references:subject:to:x-sasl-enc:x-sasl-enc; s= smtpout; bh=m7Mp6SZ2ehsYU3NHzq5+7AT8G/g=; b=DvCTOIFYEuCLeCdNm1jA FynnZYW/F17Bgk2B5yM14LDGm7Q0sdu70J2jWiHKovAJ8ryujJES4PYjcwRvogoP YzyOhXzU57nUoJP/SCuPyNa/nJBiS2QoBsY2/kLxkFNzdoEArAq8lWIEag7K4FN8 LV5HkFivLXlkW1/sOxbxtOI= X-Sasl-enc: PfJsOYknu3ijxxIQMR35ydltxs7RRGUAwlU/q5sXyJ1c 1444851440 Received: from thinkpad-t440p (unknown [2.160.102.251]) by mail.messagingengine.com (Postfix) with ESMTPA id AA6D0C00014; Wed, 14 Oct 2015 15:37:19 -0400 (EDT) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <87a8s0v1lp.fsf@gmx.de> <87twq8gyk0.fsf@gnu.org> <87lhbk47hb.fsf@gnu.org> <83d1ww4416.fsf@gnu.org> <878u75rctw.fsf@gnu.org> <836129xtx8.fsf@gnu.org> Date: Wed, 14 Oct 2015 21:37:17 +0200 Message-ID: <876129gs2a.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21313 Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 14 15:43:06 2015 Received: (at 21313) by debbugs.gnu.org; 14 Oct 2015 19:43:06 +0000 Received: from localhost ([127.0.0.1]:51160 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZmRx3-0004qq-SA for submit@debbugs.gnu.org; Wed, 14 Oct 2015 15:43:06 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:44657) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZmRx1-0004qf-MC for 21313@debbugs.gnu.org; Wed, 14 Oct 2015 15:43:04 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NW800D00679AJ00@mtaout29.012.net.il> for 21313@debbugs.gnu.org; Wed, 14 Oct 2015 22:42:25 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NW800C1R6QOG130@mtaout29.012.net.il>; Wed, 14 Oct 2015 22:42:25 +0300 (IDT) Date: Wed, 14 Oct 2015 22:43:02 +0300 From: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event In-reply-to: <876129gs2a.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <83twptw81l.fsf@gnu.org> References: <877foo4nkd.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <87a8s0v1lp.fsf@gmx.de> <87twq8gyk0.fsf@gnu.org> <87lhbk47hb.fsf@gnu.org> <83d1ww4416.fsf@gnu.org> <878u75rctw.fsf@gnu.org> <836129xtx8.fsf@gnu.org> <876129gs2a.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21313 Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 15 07:37:11 2015 Received: (at 21313) by debbugs.gnu.org; 15 Oct 2015 11:37:11 +0000 Received: from localhost ([127.0.0.1]:51541 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZmgqM-0005Lw-Vs for submit@debbugs.gnu.org; Thu, 15 Oct 2015 07:37:11 -0400 Received: from nsmtp.uni-koblenz.de ([141.26.64.14]:34689) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZmgqJ-0005Lm-Bl for 21313@debbugs.gnu.org; Thu, 15 Oct 2015 07:37:08 -0400 Received: from localhost (localhost [127.0.0.1]) by nsmtp.uni-koblenz.de (Postfix) with ESMTP id 54B5B23A264; Thu, 15 Oct 2015 13:37:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at uni-koblenz.de Received: from nsmtp.uni-koblenz.de ([127.0.0.1]) by localhost (nsmtp.uni-koblenz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikTl1CahVsOB; Thu, 15 Oct 2015 13:37:06 +0200 (CEST) Received: from deliver.uni-koblenz.de (deliver.uni-koblenz.de [141.26.64.15]) by nsmtp.uni-koblenz.de (Postfix) with ESMTPS; Thu, 15 Oct 2015 13:37:06 +0200 (CEST) Received: from thinkpad-t440p (dhcp66.uni-koblenz.de [141.26.71.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id 1BBC01A8374; Thu, 15 Oct 2015 13:37:06 +0200 (CEST) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <87a8s0v1lp.fsf@gmx.de> <87twq8gyk0.fsf@gnu.org> <87lhbk47hb.fsf@gnu.org> <83d1ww4416.fsf@gnu.org> <878u75rctw.fsf@gnu.org> <836129xtx8.fsf@gnu.org> <876129gs2a.fsf@gnu.org> <83twptw81l.fsf@gnu.org> Date: Thu, 15 Oct 2015 13:37:05 +0200 In-Reply-To: <83twptw81l.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 14 Oct 2015 22:43:02 +0300") Message-ID: <87eggwuzvi.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 21313 Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) Eli Zaretskii 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 AuthorDate: Wed Oct 14 21:22:27 2015 +0200 Commit: Tassilo Horn 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 15 12:56:32 2015 Received: (at 21313) by debbugs.gnu.org; 15 Oct 2015 16:56:32 +0000 Received: from localhost ([127.0.0.1]:52554 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZmlpQ-0004N4-Ag for submit@debbugs.gnu.org; Thu, 15 Oct 2015 12:56:32 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:35366) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZmlpN-0004Mv-KE for 21313@debbugs.gnu.org; Thu, 15 Oct 2015 12:56:30 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NW900500TDF0D00@mtaout27.012.net.il> for 21313@debbugs.gnu.org; Thu, 15 Oct 2015 19:52:24 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NW9004GATJC3V10@mtaout27.012.net.il>; Thu, 15 Oct 2015 19:52:24 +0300 (IDT) Date: Thu, 15 Oct 2015 19:56:28 +0300 From: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event In-reply-to: <87eggwuzvi.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <83d1wg8403.fsf@gnu.org> References: <877foo4nkd.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> <87r3lziti9.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <87a8s0v1lp.fsf@gmx.de> <87twq8gyk0.fsf@gnu.org> <87lhbk47hb.fsf@gnu.org> <83d1ww4416.fsf@gnu.org> <878u75rctw.fsf@gnu.org> <836129xtx8.fsf@gnu.org> <876129gs2a.fsf@gnu.org> <83twptw81l.fsf@gnu.org> <87eggwuzvi.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21313 Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 15 13:35:37 2015 Received: (at 21313) by debbugs.gnu.org; 15 Oct 2015 17:35:37 +0000 Received: from localhost ([127.0.0.1]:52582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZmmRF-0005I4-6a for submit@debbugs.gnu.org; Thu, 15 Oct 2015 13:35:37 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:57443) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZmmRC-0005Hw-Uo for 21313@debbugs.gnu.org; Thu, 15 Oct 2015 13:35:36 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6D57A218A0 for <21313@debbugs.gnu.org>; Thu, 15 Oct 2015 13:35:34 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Thu, 15 Oct 2015 13:35:34 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=kVWYNc3TNaV/7MNP5mD8uCDBOJ8=; b=C6TUb dIISv3abVDH2x6eL6XB/4dSL3pGx82qldt2+PHZQahz0IsvdAIvHFr3ObnG+vJ/6 y06jjH6wCDAQdBl/2uCZnPTocktzCqMsk7q5n92iitdLMlzNwQpZtSdQWZsIZq3v x59AqnY/qANj6wiy5kWrzW/6r6bQJQUTXyU+GY= X-Sasl-enc: R7rCc4tqDSGdKuTlQ7lf+/v6STDriAHY64yiXm31G4Rb 1444930533 Received: from thinkpad-t440p (unknown [2.163.85.14]) by mail.messagingengine.com (Postfix) with ESMTPA id 838C0680157; Thu, 15 Oct 2015 13:35:33 -0400 (EDT) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <87a8s0v1lp.fsf@gmx.de> <87twq8gyk0.fsf@gnu.org> <87lhbk47hb.fsf@gnu.org> <83d1ww4416.fsf@gnu.org> <878u75rctw.fsf@gnu.org> <836129xtx8.fsf@gnu.org> <876129gs2a.fsf@gnu.org> <83twptw81l.fsf@gnu.org> <87eggwuzvi.fsf@gnu.org> <83d1wg8403.fsf@gnu.org> Date: Thu, 15 Oct 2015 19:35:31 +0200 In-Reply-To: <83d1wg8403.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 15 Oct 2015 19:56:28 +0300") Message-ID: <87twps9grg.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21313 Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 15 15:46:03 2015 Received: (at 21313) by debbugs.gnu.org; 15 Oct 2015 19:46:03 +0000 Received: from localhost ([127.0.0.1]:52629 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZmoTS-0008Lk-O1 for submit@debbugs.gnu.org; Thu, 15 Oct 2015 15:46:02 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:40012) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZmoTQ-0008LE-1d for 21313@debbugs.gnu.org; Thu, 15 Oct 2015 15:46:01 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NWA00L001CV0500@a-mtaout20.012.net.il> for 21313@debbugs.gnu.org; Thu, 15 Oct 2015 22:44:45 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWA00KY91IKTB70@a-mtaout20.012.net.il>; Thu, 15 Oct 2015 22:44:45 +0300 (IDT) Date: Thu, 15 Oct 2015 22:44:45 +0300 From: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event In-reply-to: <87twps9grg.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <837fmn9as2.fsf@gnu.org> References: <877foo4nkd.fsf@gnu.org> <83zj0n7jtl.fsf@gnu.org> <87wpvjovfu.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <87a8s0v1lp.fsf@gmx.de> <87twq8gyk0.fsf@gnu.org> <87lhbk47hb.fsf@gnu.org> <83d1ww4416.fsf@gnu.org> <878u75rctw.fsf@gnu.org> <836129xtx8.fsf@gnu.org> <876129gs2a.fsf@gnu.org> <83twptw81l.fsf@gnu.org> <87eggwuzvi.fsf@gnu.org> <83d1wg8403.fsf@gnu.org> <87twps9grg.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21313 Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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); From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 16 00:53:27 2015 Received: (at 21313) by debbugs.gnu.org; 16 Oct 2015 04:53:27 +0000 Received: from localhost ([127.0.0.1]:52952 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zmx1D-0007XR-4T for submit@debbugs.gnu.org; Fri, 16 Oct 2015 00:53:27 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:34111) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zmx1A-0007XI-7o for 21313@debbugs.gnu.org; Fri, 16 Oct 2015 00:53:25 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A2D5120444 for <21313@debbugs.gnu.org>; Fri, 16 Oct 2015 00:53:23 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Fri, 16 Oct 2015 00:53:23 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=G7ddehaaeCf5Yh0eDZKUtf2/Aso=; b=lYADe DwWVa40sJWfR/NWUifhVgz4Ertvjnt6/eZsU0umUqk1cZ61xZr1m+k2mRtDYtoXW IS3ne8VgTiVR6faQkMJwW5/UhPq1g+TF5vroNb0xqnacp25p6nyMRm/1pfO8L9IJ H/9sNQxKx0jFqKSayxwHkJtCGc4D3EEdYHicq0= X-Sasl-enc: lhKLVlCyXoPL5Z2PDlauZtOjWpUkMUmKCgP248XvRxSJ 1444971203 Received: from thinkpad-t440p (unknown [2.163.5.132]) by mail.messagingengine.com (Postfix) with ESMTPA id 9B893680119; Fri, 16 Oct 2015 00:53:22 -0400 (EDT) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <87a8s0v1lp.fsf@gmx.de> <87twq8gyk0.fsf@gnu.org> <87lhbk47hb.fsf@gnu.org> <83d1ww4416.fsf@gnu.org> <878u75rctw.fsf@gnu.org> <836129xtx8.fsf@gnu.org> <876129gs2a.fsf@gnu.org> <83twptw81l.fsf@gnu.org> <87eggwuzvi.fsf@gnu.org> <83d1wg8403.fsf@gnu.org> <87twps9grg.fsf@gnu.org> <837fmn9as2.fsf@gnu.org> Date: Fri, 16 Oct 2015 06:53:19 +0200 In-Reply-To: <837fmn9as2.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 15 Oct 2015 22:44:45 +0300") Message-ID: <87pp0fo1mo.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21313 Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 16 03:02:10 2015 Received: (at 21313) by debbugs.gnu.org; 16 Oct 2015 07:02:10 +0000 Received: from localhost ([127.0.0.1]:52970 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zmz1m-0002Ab-9l for submit@debbugs.gnu.org; Fri, 16 Oct 2015 03:02:10 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:41918) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zmz1k-0002AS-4x for 21313@debbugs.gnu.org; Fri, 16 Oct 2015 03:02:09 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NWA00600WH9LB00@mtaout28.012.net.il> for 21313@debbugs.gnu.org; Fri, 16 Oct 2015 10:01:25 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWA000YZWUDZV60@mtaout28.012.net.il>; Fri, 16 Oct 2015 10:01:25 +0300 (IDT) Date: Fri, 16 Oct 2015 10:02:08 +0300 From: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event In-reply-to: <87pp0fo1mo.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <83pp0f70un.fsf@gnu.org> References: <877foo4nkd.fsf@gnu.org> <877fnikhms.fsf@gmail.com> <87oaguq2yw.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <87a8s0v1lp.fsf@gmx.de> <87twq8gyk0.fsf@gnu.org> <87lhbk47hb.fsf@gnu.org> <83d1ww4416.fsf@gnu.org> <878u75rctw.fsf@gnu.org> <836129xtx8.fsf@gnu.org> <876129gs2a.fsf@gnu.org> <83twptw81l.fsf@gnu.org> <87eggwuzvi.fsf@gnu.org> <83d1wg8403.fsf@gnu.org> <87twps9grg.fsf@gnu.org> <837fmn9as2.fsf@gnu.org> <87pp0fo1mo.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21313 Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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.) From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 16 03:45:15 2015 Received: (at 21313) by debbugs.gnu.org; 16 Oct 2015 07:45:15 +0000 Received: from localhost ([127.0.0.1]:53016 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZmzhT-0003B0-4m for submit@debbugs.gnu.org; Fri, 16 Oct 2015 03:45:15 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:47388) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZmzhQ-0003Ar-2y for 21313@debbugs.gnu.org; Fri, 16 Oct 2015 03:45:12 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9A832208EC for <21313@debbugs.gnu.org>; Fri, 16 Oct 2015 03:45:11 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 16 Oct 2015 03:45:11 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=BigEyxZtpMxHRuRMiWdCmtpbzkc=; b=fMuf8 Oc6F5+usbopyIr0ZzmXV40p5kZZUAL5UmbPQJQQ6S+MI/hOkJqKNLzj1syvgg1Ji /1TQwdxgePYbe0wWH5zR0MomdpUHJV2c16yZkIB5nA1nA5jYw+iZHrh2TUHJWlbU 9eINfExqY8FWzYxJ6N2h4iZprmkomSACHVYaLs= X-Sasl-enc: 1tN0ZM6Wlvqee+ksw8HBQujBhGfebnJkqZByjWd9kO8g 1444981511 Received: from thinkpad-t440p (unknown [2.163.5.132]) by mail.messagingengine.com (Postfix) with ESMTPA id 67262C00013; Fri, 16 Oct 2015 03:45:10 -0400 (EDT) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <87a8s0v1lp.fsf@gmx.de> <87twq8gyk0.fsf@gnu.org> <87lhbk47hb.fsf@gnu.org> <83d1ww4416.fsf@gnu.org> <878u75rctw.fsf@gnu.org> <836129xtx8.fsf@gnu.org> <876129gs2a.fsf@gnu.org> <83twptw81l.fsf@gnu.org> <87eggwuzvi.fsf@gnu.org> <83d1wg8403.fsf@gnu.org> <87twps9grg.fsf@gnu.org> <837fmn9as2.fsf@gnu.org> <87pp0fo1mo.fsf@gnu.org> <83pp0f70un.fsf@gnu.org> Date: Fri, 16 Oct 2015 09:45:08 +0200 In-Reply-To: <83pp0f70un.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 16 Oct 2015 10:02:08 +0300") Message-ID: <871tcv5kaj.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21313 Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 16 04:23:52 2015 Received: (at 21313) by debbugs.gnu.org; 16 Oct 2015 08:23:52 +0000 Received: from localhost ([127.0.0.1]:53054 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zn0Iq-00044U-01 for submit@debbugs.gnu.org; Fri, 16 Oct 2015 04:23:52 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:34390) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zn0In-00044K-D6 for 21313@debbugs.gnu.org; Fri, 16 Oct 2015 04:23:50 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NWB000000L08Z00@mtaout28.012.net.il> for 21313@debbugs.gnu.org; Fri, 16 Oct 2015 11:22:36 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWB00DVF0LOP5A0@mtaout28.012.net.il>; Fri, 16 Oct 2015 11:22:36 +0300 (IDT) Date: Fri, 16 Oct 2015 11:23:19 +0300 From: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event In-reply-to: <871tcv5kaj.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <83h9lr6x3c.fsf@gnu.org> References: <877foo4nkd.fsf@gnu.org> <8737xtt8wt.fsf@gnu.org> <834mi95bx1.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <87a8s0v1lp.fsf@gmx.de> <87twq8gyk0.fsf@gnu.org> <87lhbk47hb.fsf@gnu.org> <83d1ww4416.fsf@gnu.org> <878u75rctw.fsf@gnu.org> <836129xtx8.fsf@gnu.org> <876129gs2a.fsf@gnu.org> <83twptw81l.fsf@gnu.org> <87eggwuzvi.fsf@gnu.org> <83d1wg8403.fsf@gnu.org> <87twps9grg.fsf@gnu.org> <837fmn9as2.fsf@gnu.org> <87pp0fo1mo.fsf@gnu.org> <83pp0f70un.fsf@gnu.org> <871tcv5kaj.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21313 Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 16 05:25:43 2015 Received: (at 21313) by debbugs.gnu.org; 16 Oct 2015 09:25:43 +0000 Received: from localhost ([127.0.0.1]:53099 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zn1Gh-0005VE-30 for submit@debbugs.gnu.org; Fri, 16 Oct 2015 05:25:43 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:51355) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zn1Gf-0005V6-7Y for 21313@debbugs.gnu.org; Fri, 16 Oct 2015 05:25:42 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id AE8E720715 for <21313@debbugs.gnu.org>; Fri, 16 Oct 2015 05:25:40 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 16 Oct 2015 05:25:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=xnADiJ5oLyNU+fLiN9nvo9NgI9M=; b=ffPar Z9UZMzRiwtM4gC9o3U6s9dSqH4WyNobSIkDUaYwjPE0bAZp7DGi1dFOJUz89Htgv MSxnyWPJAX3+vOu64S3RtdtH8hM6uv+TDNyH+l7UBM7GfFVuee2pqM1hOFYPT+H7 GodrjUcteU+60VlFFnc8hhmuMBDYVsbMrNGjUM= X-Sasl-enc: NxFvoDqC+rtNvZx1NUqKAfuIi3M39sT7jL/rt8wWe0Mh 1444987540 Received: from thinkpad-t440p (unknown [2.163.5.132]) by mail.messagingengine.com (Postfix) with ESMTPA id 7CC1DC00019; Fri, 16 Oct 2015 05:25:39 -0400 (EDT) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <87a8s0v1lp.fsf@gmx.de> <87twq8gyk0.fsf@gnu.org> <87lhbk47hb.fsf@gnu.org> <83d1ww4416.fsf@gnu.org> <878u75rctw.fsf@gnu.org> <836129xtx8.fsf@gnu.org> <876129gs2a.fsf@gnu.org> <83twptw81l.fsf@gnu.org> <87eggwuzvi.fsf@gnu.org> <83d1wg8403.fsf@gnu.org> <87twps9grg.fsf@gnu.org> <837fmn9as2.fsf@gnu.org> <87pp0fo1mo.fsf@gnu.org> <83pp0f70un.fsf@gnu.org> <871tcv5kaj.fsf@gnu.org> <83h9lr6x3c.fsf@gnu.org> Date: Fri, 16 Oct 2015 11:25:36 +0200 In-Reply-To: <83h9lr6x3c.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 16 Oct 2015 11:23:19 +0300") Message-ID: <87oafz412n.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21313 Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 16 06:11:37 2015 Received: (at 21313) by debbugs.gnu.org; 16 Oct 2015 10:11:37 +0000 Received: from localhost ([127.0.0.1]:53132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zn1z6-0006Yo-Vb for submit@debbugs.gnu.org; Fri, 16 Oct 2015 06:11:37 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:46704) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zn1z4-0006Yf-9r for 21313@debbugs.gnu.org; Fri, 16 Oct 2015 06:11:35 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NWB00K0058HMB00@mtaout25.012.net.il> for 21313@debbugs.gnu.org; Fri, 16 Oct 2015 13:09:08 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWB00IYF5J8HL20@mtaout25.012.net.il>; Fri, 16 Oct 2015 13:09:08 +0300 (IDT) Date: Fri, 16 Oct 2015 13:11:35 +0300 From: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event In-reply-to: <87oafz412n.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <83zizj5dig.fsf@gnu.org> References: <877foo4nkd.fsf@gnu.org> <87twq9roxn.fsf@gnu.org> <83wpv53rjn.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <87a8s0v1lp.fsf@gmx.de> <87twq8gyk0.fsf@gnu.org> <87lhbk47hb.fsf@gnu.org> <83d1ww4416.fsf@gnu.org> <878u75rctw.fsf@gnu.org> <836129xtx8.fsf@gnu.org> <876129gs2a.fsf@gnu.org> <83twptw81l.fsf@gnu.org> <87eggwuzvi.fsf@gnu.org> <83d1wg8403.fsf@gnu.org> <87twps9grg.fsf@gnu.org> <837fmn9as2.fsf@gnu.org> <87pp0fo1mo.fsf@gnu.org> <83pp0f70un.fsf@gnu.org> <871tcv5kaj.fsf@gnu.org> <83h9lr6x3c.fsf@gnu.org> <87oafz412n.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21313 Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 16 06:22:16 2015 Received: (at 21313) by debbugs.gnu.org; 16 Oct 2015 10:22:16 +0000 Received: from localhost ([127.0.0.1]:53139 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zn29Q-0006nx-8Y for submit@debbugs.gnu.org; Fri, 16 Oct 2015 06:22:16 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:55235) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zn29O-0006no-8p for 21313@debbugs.gnu.org; Fri, 16 Oct 2015 06:22:14 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 3C74521451 for <21313@debbugs.gnu.org>; Fri, 16 Oct 2015 06:22:12 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Fri, 16 Oct 2015 06:22:12 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=+H/hePVDXGp3KYYC9FUiT04nQeo=; b=mTuU+ bFakid0T8Yj7cJ+6RH93s5G1mesfzSyy5sx5Nn7SBZuHCD83fATegXzmFr5MdZFn SIXdOo1V1nRsyVrESzO7LRIzwzOOqCHCjMfgqmFLoThlxMqYttrCNjGjN89DoiMO YVrshJAQJFDroDUFZCJ/RyITFBziK0rVjdknQA= X-Sasl-enc: aB37QqlpopaQNje9BbFUQDrRxJcV5p/nXNTXKEltQIq0 1444990931 Received: from thinkpad-t440p (unknown [2.163.5.132]) by mail.messagingengine.com (Postfix) with ESMTPA id 05F4D6801B8; Fri, 16 Oct 2015 06:22:10 -0400 (EDT) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <87h9m9rmgk.fsf@gmx.de> <87wpv4qzm2.fsf@gnu.org> <87a8s0v1lp.fsf@gmx.de> <87twq8gyk0.fsf@gnu.org> <87lhbk47hb.fsf@gnu.org> <83d1ww4416.fsf@gnu.org> <878u75rctw.fsf@gnu.org> <836129xtx8.fsf@gnu.org> <876129gs2a.fsf@gnu.org> <83twptw81l.fsf@gnu.org> <87eggwuzvi.fsf@gnu.org> <83d1wg8403.fsf@gnu.org> <87twps9grg.fsf@gnu.org> <837fmn9as2.fsf@gnu.org> <87pp0fo1mo.fsf@gnu.org> <83pp0f70un.fsf@gnu.org> <871tcv5kaj.fsf@gnu.org> <83h9lr6x3c.fsf@gnu.org> <87oafz412n.fsf@gnu.org> <83zizj5dig.fsf@gnu.org> Date: Fri, 16 Oct 2015 12:22:08 +0200 In-Reply-To: <83zizj5dig.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 16 Oct 2015 13:11:35 +0300") Message-ID: <87fv1b3ygf.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21313 Cc: michael.albinus@gmx.de, 21313@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 29 03:43:43 2015 Received: (at 21313-done) by debbugs.gnu.org; 29 Oct 2015 07:43:44 +0000 Received: from localhost ([127.0.0.1]:43174 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zrhs7-0005vU-Gj for submit@debbugs.gnu.org; Thu, 29 Oct 2015 03:43:43 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:60249) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zrhs6-0005vM-5K for 21313-done@debbugs.gnu.org; Thu, 29 Oct 2015 03:43:42 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id DC9672025A for <21313-done@debbugs.gnu.org>; Thu, 29 Oct 2015 03:43:41 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 29 Oct 2015 03:43:41 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=qdheb2aYfFY7XiUlLVxRT3sjiio=; b=McLUt Qvaxn0Htkt4CebvMDzswOcceXMb2S0ZxjWXNxXuEhtpVnq4y1Jofgb6Fx2tunGtu kGHnI9UFURtuVvnIAfNp1K0fj+MWbEJMtDGlbj8ZMiAkdRs0Iki1cZQ4Ac18pLvW qnD+qxokqxUWbojPjEW3VsiodF12Zcqni9uXUA= X-Sasl-enc: VfwmgXuMFZheCLL/kqfiiX68A3jfUUNFvdnvhFXgrvRx 1446104621 Received: from thinkpad-t440p (unknown [2.160.89.142]) by mail.messagingengine.com (Postfix) with ESMTPA id A86AC6801B2; Thu, 29 Oct 2015 03:43:40 -0400 (EDT) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event References: <877foo4nkd.fsf@gnu.org> <87wpv4qzm2.fsf@gnu.org> <87a8s0v1lp.fsf@gmx.de> <87twq8gyk0.fsf@gnu.org> <87lhbk47hb.fsf@gnu.org> <83d1ww4416.fsf@gnu.org> <878u75rctw.fsf@gnu.org> <836129xtx8.fsf@gnu.org> <876129gs2a.fsf@gnu.org> <83twptw81l.fsf@gnu.org> <87eggwuzvi.fsf@gnu.org> <83d1wg8403.fsf@gnu.org> <87twps9grg.fsf@gnu.org> <837fmn9as2.fsf@gnu.org> <87pp0fo1mo.fsf@gnu.org> <83pp0f70un.fsf@gnu.org> <871tcv5kaj.fsf@gnu.org> <83h9lr6x3c.fsf@gnu.org> <87oafz412n.fsf@gnu.org> <83zizj5dig.fsf@gnu.org> <87fv1b3ygf.fsf@gnu.org> Date: Thu, 29 Oct 2015 08:43:29 +0100 In-Reply-To: <87fv1b3ygf.fsf@gnu.org> (Tassilo Horn's message of "Fri, 16 Oct 2015 12:22:08 +0200") Message-ID: <871tce3yse.fsf@gnu.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21313-done Cc: michael.albinus@gmx.de, 21313-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 29 12:20:18 2015 Received: (at 21313-done) by debbugs.gnu.org; 29 Oct 2015 16:20:18 +0000 Received: from localhost ([127.0.0.1]:44456 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zrpw1-00033a-PD for submit@debbugs.gnu.org; Thu, 29 Oct 2015 12:20:18 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:48427) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zrpw0-00033R-BO for 21313-done@debbugs.gnu.org; Thu, 29 Oct 2015 12:20:17 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NWZ00I00OZYNB00@a-mtaout23.012.net.il> for 21313-done@debbugs.gnu.org; Thu, 29 Oct 2015 18:19:25 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWZ00IKLPCCK770@a-mtaout23.012.net.il>; Thu, 29 Oct 2015 18:19:25 +0200 (IST) Date: Thu, 29 Oct 2015 18:19:27 +0200 From: Eli Zaretskii Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event In-reply-to: <871tce3yse.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <831tcd3awg.fsf@gnu.org> References: <877foo4nkd.fsf@gnu.org> <87wpv4qzm2.fsf@gnu.org> <87a8s0v1lp.fsf@gmx.de> <87twq8gyk0.fsf@gnu.org> <87lhbk47hb.fsf@gnu.org> <83d1ww4416.fsf@gnu.org> <878u75rctw.fsf@gnu.org> <836129xtx8.fsf@gnu.org> <876129gs2a.fsf@gnu.org> <83twptw81l.fsf@gnu.org> <87eggwuzvi.fsf@gnu.org> <83d1wg8403.fsf@gnu.org> <87twps9grg.fsf@gnu.org> <837fmn9as2.fsf@gnu.org> <87pp0fo1mo.fsf@gnu.org> <83pp0f70un.fsf@gnu.org> <871tcv5kaj.fsf@gnu.org> <83h9lr6x3c.fsf@gnu.org> <87oafz412n.fsf@gnu.org> <83zizj5dig.fsf@gnu.org> <87fv1b3ygf.fsf@gnu.org> <871tce3yse.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21313-done Cc: michael.albinus@gmx.de, 21313-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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. From unknown Mon Jun 23 07:49:16 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 27 Nov 2015 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator