From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/53336 Path: main.gmane.org!not-for-mail From: Gaute B Strokkenes Newsgroups: gmane.emacs.gnus.general Subject: Re: nnimap versus tls Date: Sun, 06 Jul 2003 13:56:41 +0100 Organization: The Church of Emacs Sender: ding-owner@lists.math.uh.edu Message-ID: <87adbrq0dy.fsf@cam.ac.uk> References: <87ptmfhxj6.fsf@cam.ac.uk> <84of0ab15z.fsf@lucy.is.informatik.uni-duisburg.de> <87k7axwef3.fsf@cam.ac.uk> <843chlyw19.fsf@lucy.is.informatik.uni-duisburg.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1057499870 10509 80.91.224.249 (6 Jul 2003 13:57:50 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 6 Jul 2003 13:57:50 +0000 (UTC) Original-X-From: ding-owner+M1880@lists.math.uh.edu Sun Jul 06 15:57:48 2003 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19ZA1T-0002jG-00 for ; Sun, 06 Jul 2003 15:57:47 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19ZA1A-000433-00; Sun, 06 Jul 2003 08:57:28 -0500 Original-Received: from util1.math.uh.edu ([129.7.128.22]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 19ZA15-00042y-00 for ding@lists.math.uh.edu; Sun, 06 Jul 2003 08:57:23 -0500 Original-Received: from sclp3.sclp.com ([64.157.176.121]) by util1.math.uh.edu with smtp (Exim 4.20) id 19ZA15-00059Y-82 for ding@lists.math.uh.edu; Sun, 06 Jul 2003 08:57:23 -0500 Original-Received: (qmail 51354 invoked by alias); 6 Jul 2003 12:57:21 -0000 Original-Received: (qmail 51349 invoked from network); 6 Jul 2003 12:57:21 -0000 Original-Received: from mta01-svc.ntlworld.com (62.253.162.41) by sclp3.sclp.com with SMTP; 6 Jul 2003 12:57:21 -0000 Original-Received: from belldandy ([81.100.93.186]) by mta01-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20030706125717.UVTE21249.mta01-svc.ntlworld.com@belldandy> for ; Sun, 6 Jul 2003 13:57:17 +0100 Original-Received: from gs234 by belldandy with local (Exim 3.36 #1 (Debian)) id 19Z94L-0003LW-00 for ; Sun, 06 Jul 2003 13:56:41 +0100 Mail-Copies-To: never Original-To: ding@gnus.org Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEWWWBTly7aGMwb+/vz9 +ffIilb///+yaCxNCwHGVC3gAAACU0lEQVR4nF2TQWvjMBBGVUGwj3WxaY/aAWNfi0zuwZPuHp0Q ob079OwYjHrsChb0s3dGctJ0ddTzm9F8lsR7WiNiWWL/flviul9Uh0NR4vY/gJUxJjOEtt/AubBy UsotRfH2DbxWE0hom3w5XJUEKis9hACt2hR4B86VDOtqTNHfgeEGvLiUN7Ddze26Dx6y1CUa+ygo NwFQm0N/BeMzCZAtNIoQrd9EhcH5mWpnztB8ZpJBlH23jaAbuE4EhZ2Bam0TeJ0DRMCKVP6CegWk q4z2TVFUx0946FOPcSe9ELE3rSHAj15rBuddS0C4BGyAutfpVAQkKdZOQiwMMIHxlUDrgeej5Ns7 I/ccSWNBLda1XwYBEG1Qswy1yXJf879nA4cjkNI0H+FzoUyuRodPA5eqZwFONG34i30ccOxeKFUy flNe1szqsgLdvXwKCj6zjTXODHV9M46gZPCLlYKCGTYO8S0aOAvJzRfD0w+1XcGIsxLUw/sYl5sM 9n0yjkoSUDOByrijwRRiAq13NhqLJYB3ACazrgN2bIwanyJQKXhHAJPRPQruEaCJP2Shy4DJ2As+ FQjJZH7AZIy6w0pQiiRYAh8nTEZHYDfRqSDeB5OXq4EEcAC4NocvoBl4+n1cyl54nyLRNA3iIwRP wNGFOK1g1Gz8jNfaCjdtqJLm2LXuqMc+50cDIJQpr6X0OHa4X58ULAw03QbRd7GUiG/K04mj0bNB xQhwJkEsJiZ1Bbgb6CnF79cBE+jwF91qniOCP3fghUFKxOShjIATw/wOfIQTg39LpFHtxhlKywAA AABJRU5ErkJggg== User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux) X-Spam-Score: -1.8 (-) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:53336 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:53336 On 5 jul 2003, kai.grossjohann@gmx.net wrote: > There are only two places in imap.el where a buffer is killed. This > happens when imap.el tries more than one stream to open a connection > to the remote end. I wonder if that is the problem? Can you follow > things on opening the connection to see if this is the cause? I tried the following: Index: lisp/imap.el =================================================================== RCS file: /usr/local/cvsroot/gnus/lisp/imap.el,v retrieving revision 6.52 diff -u -r6.52 imap.el --- lisp/imap.el 20 Apr 2003 13:44:27 -0000 6.52 +++ lisp/imap.el 6 Jul 2003 12:34:36 -0000 @@ -995,12 +995,14 @@ (if (null (let ((imap-stream stream)) (imap-open-1 (current-buffer)))) (progn + (message "kb1: killing buffer `%s'" (current-buffer)) (kill-buffer (current-buffer)) (message "imap: Reconnecting with stream `%s'...failed" stream)) ;; We're done, kill the first connection (imap-close buffer) + (message "kb2: killing buffer `%s'" buffer) (kill-buffer buffer) (rename-buffer buffer) (message "imap: Reconnecting with stream `%s'...done" @@ -1739,6 +1741,7 @@ tag))) (defun imap-wait-for-tag (tag &optional buffer) + (message "imap: waiting for tag `%s'" tag) (with-current-buffer (or buffer (current-buffer)) (let (imap-have-messaged) (while (and (null imap-continuation) @@ -1758,9 +1761,11 @@ (message "")) (and (memq (process-status imap-process) '(open run)) (or (assq tag imap-failed-tags) - (if imap-continuation - 'INCOMPLETE - 'OK)))))) + (progn + (message "imap: done waiting for tag `%s'" tag) + (if imap-continuation + 'INCOMPLETE + 'OK))))))) (defun imap-sentinel (process string) (delete-process process)) @@ -1780,6 +1785,9 @@ (defun imap-arrival-filter (proc string) "IMAP process filter." + (message "IAF: trying to grab buffer `%s', proc `%s'" + (process-buffer proc) + proc) (with-current-buffer (process-buffer proc) (goto-char (point-max)) (insert string) I set message-log-max to an insanely large number and waited for the bug to trigger. However, no such message appears in the *Message* buffer. Reading active file via nnml... nnml: Reading incoming mail from imap... imap: Connecting to imap.srcf.ucam.org... Opening TLS connection to `imap.srcf.ucam.org'... Opening TLS connection with `gnutls-cli -p %p %h'...done Opening TLS connection to `imap.srcf.ucam.org'...done Waiting for response from imap.srcf.ucam.org...done imap: waiting for tag `1' imap: done waiting for tag `1' imap: Authenticating to `imap.srcf.ucam.org' using `login'... imap: Plaintext authentication... imap: waiting for tag `2' imap: done waiting for tag `2' imap: Authenticating to `imap.srcf.ucam.org' using `login'...done imap: waiting for tag `3' imap: done waiting for tag `3' imap: waiting for tag `4' imap: done waiting for tag `4' imap: waiting for tag `5' imap: done waiting for tag `5' imap: waiting for tag `6' Notice how we never get "done waiting for tag `6'" nnml: Reading incoming mail from file... nnml: Reading incoming mail (no new mail)...done Reading active file via nnml...done Reading active file from news.gmane.org via nntp... Opening nntp server on news.gmane.org...done Reading active file from archive via nnfolder...done Checking new news...done (No changes need to be saved) IAF: trying to grab buffer `#', proc `imap<1>' Loading debug...done Entering debugger... [2 times] Mark set [3 times] Having thought about this for a bit, I suspect that this is some sort of timing problem. I think that when gnus sends the LOGOUT command it does not hang around and wait for the server to say goodbye, but closes the connection of its own accord. If gnus kills the connection by first killing (process-buffer proc) and _then_ removes the process proper (and the filter, imap-arrival-filter) then the possibility exists that the final bit of chit-chat from the imap server ends up being processed after the buffer has been killed, but before the filter has been removed. This would cause the filter to throw an error, like we see. The timing dependence would also account for the intermittent nature of this bug. Now, looking at the above it seems that the filter does not get to process anything until after all the other processing that happens when I hit `g' in the group buffer is done. I can imagine one slight complication here--I have more than one imap process running. That is, I keep most of my mail on a secondary nnimap server, in addition to which I use an imap mail-source (well, actually I use fetchmail ATM but I would like to use gnus) to get mail from another account (which I use for mailing lists and such). I have explicitly set the imap mail-source to use :stream tls, but I have not done this for the nnimap server. Moreover, when I comment out the imap mail-source and set the nnimap server to :stream tls I find it difficult to reproduce this bug. Thus, one possible twist on my hypothesis could be that imap.el, when handling my nnimap server, accidentally deletes a buffer that pertains to my imap mail-source. I don't know how the emacs process stuff works, and I don't really understand how imap.el works either. Unfortunately. One other thing I should mention is that I do not seem to meet with succes when I try to use (message "foo") to print debugging messages in imap-arrival-filter; I'm _sure_ I see message flicker onto my screen, but I cannot find them in the *Message* buffer afterwards. Possibly this is just more magick that I am not familiar with. -- Gaute Strokkenes http://www.srcf.ucam.org/~gs234/ I can't decide which WRONG TURN to make first!! I wonder if BOB GUCCIONE has these problems!