From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 10 17:24:20 2010 Received: (at submit) by debbugs.gnu.org; 10 Apr 2010 21:24:20 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0iA7-0004cW-LM for submit@debbugs.gnu.org; Sat, 10 Apr 2010 17:24:20 -0400 Received: from mx10.gnu.org ([199.232.76.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0iA5-0004cP-RT for submit@debbugs.gnu.org; Sat, 10 Apr 2010 17:24:18 -0400 Received: from lists.gnu.org ([199.232.76.165]:40702) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1O0iA3-0003EL-V0 for submit@debbugs.gnu.org; Sat, 10 Apr 2010 17:24:16 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O0iA3-0000Qj-C1 for bug-gnu-emacs@gnu.org; Sat, 10 Apr 2010 17:24:15 -0400 Received: from [140.186.70.92] (port=49252 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O0iA0-0000P8-V8 for bug-gnu-emacs@gnu.org; Sat, 10 Apr 2010 17:24:15 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O0i9z-0002yH-0B for bug-gnu-emacs@gnu.org; Sat, 10 Apr 2010 17:24:12 -0400 Received: from sun60.bham.ac.uk ([147.188.128.137]:50373) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0i9y-0002y1-Rm for bug-gnu-emacs@gnu.org; Sat, 10 Apr 2010 17:24:10 -0400 Received: from [147.188.128.127] (helo=bham.ac.uk) by sun60.bham.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1O0i9v-0002HP-PI for bug-gnu-emacs@gnu.org; Sat, 10 Apr 2010 22:24:07 +0100 Received: from mx1.cs.bham.ac.uk ([147.188.192.53]) by bham.ac.uk with esmtp (Exim 4.43) id 1O0i9v-0001F7-FP for bug-gnu-emacs@gnu.org; Sat, 10 Apr 2010 22:24:07 +0100 Received: from gromit.cs.bham.ac.uk ([147.188.193.16] helo=MARUTI.cs.bham.ac.uk) by mx1.cs.bham.ac.uk with esmtp (Exim 4.51) id 1O0i9v-0002QC-Eb; Sat, 10 Apr 2010 22:24:07 +0100 Date: Sat, 10 Apr 2010 22:23:57 +0100 Message-Id: <84mxxbknma.fsf@cs.bham.ac.uk> From: Uday S Reddy To: bug-gnu-emacs@gnu.org Subject: 23.1; accept-process-output switching current-buffer X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: submit Cc: U.S.Reddy@cs.bham.ac.uk X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.4 (-----) Reading the elisp manual doesn't indicate anywhere that a call such as (accept-process-output process) should change the current-buffer. But it is happening. It led to some hairy asynchronous errors that took me an entire week to track down. Finally, I found an instance that was sort of reproducible, and tested it with a code fragment such as this: (let ((wait nil) (buffer-x (current-buffer))) ... (if (not (equal (current-buffer) buffer-x)) (debug nil wait)) (setq wait t) (accept-process-output process) (if (not (equal (current-buffer) buffer-x)) (debug nil wait)) (setq wait nil) ... ) If the debugger is entered with the argument 't' that means that the call to accept-process-output changed the 'current-buffer'. The following backtrace was obtained: Debugger entered: (t) vm-imap-read-object(#> t) vm-imap-read-object(#>) vm-imap-read-response(#>) vm-imap-read-response-and-verify(#> "FLAGS FETCH") vm-imap-get-message-data-list(#> 1 3672) vm-imap-retrieve-uid-and-flags-data() vm-imap-get-synchronization-data(t) vm-imap-synchronize-folder(t nil t t t t) vm-get-spooled-mail(t) vm-get-new-mail(nil) call-interactively(vm-get-new-mail nil nil) The full file containing the code, VM's IMAP client, is attached. The misbehaving accept-process-output call is in the vm-imap-read-object function. My theory of what happened here is as follows: VM ended an existing IMAP session (#) by sending a LOGOUT command, and created a new one (#>). While it was working with the second session, in the process-buffer, the server must have sent back some response to the first session, which would have been accepted during a call to accept-process-output. This caused the current-buffer to change to the process-buffer of the original session. I found the problem orignally in Emacs 22.2, but checking it with 23.1 shows that the problem is still present in the current version. Cheers, Uday ----- In GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600) of 2009-07-30 on SOFT-MJASON Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.4)' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: C.UTF-8 value of $XMODIFIERS: nil locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: VM Summary Minor modes in effect: savehist-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t global-auto-composition-mode: t auto-encryption-mode: t line-number-mode: t transient-mark-mode: t Recent input: g C-p C-p C-SPC C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-x C-k C-x C-f d : / g n u SPC v m SPC t r u SPC / SPC e m SPC b u SPC SPC SPC SPC - e m a c s 2 3 . t x t C-y C-x , C-x C-s C-h i m e l SPC SPC C-s p r o c e s s C-a m SPC m o u t p u t SPC SPC C-x b q C-x , q C-x u C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-k C-x C-s C-x b * B SPC q C-x m C-x k M-x v m r e p o r t - e m SPC SPC Recent messages: Composing main Info directory...done Mark saved where search started Mark set Undo! Saving file d:/gnu/vm/trunk/bug-accept-process-output-emacs23.txt... Wrote d:/gnu/vm/trunk/bug-accept-process-output-emacs23.txt Back to top level. Parsing d:/Home/udr/.mailrc... Parsing y:/dotfiles/.mailrc... done Parsing d:/Home/udr/.mailrc... done ------ [ATTACHMENT d:/gnu/vm/trunk23/lisp/vm-imap.el, text/plain] From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 10 22:54:55 2010 Received: (at 5924) by debbugs.gnu.org; 11 Apr 2010 02:54:55 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0nK3-0007J9-Dv for submit@debbugs.gnu.org; Sat, 10 Apr 2010 22:54:55 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.183] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0nK2-0007J4-2B for 5924@debbugs.gnu.org; Sat, 10 Apr 2010 22:54:54 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFvXwEtMCqWu/2dsb2JhbACbQ3K3DoUMBItGgwI X-IronPort-AV: E=Sophos;i="4.52,183,1270440000"; d="scan'208";a="60611623" Received: from 76-10-165-174.dsl.teksavvy.com (HELO ceviche.home) ([76.10.165.174]) by ironport2-out.pppoe.ca with ESMTP; 10 Apr 2010 22:54:44 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 600FC660BF; Sat, 10 Apr 2010 22:54:44 -0400 (EDT) From: Stefan Monnier To: Uday S Reddy Subject: Re: bug#5924: 23.1; accept-process-output switching current-buffer Message-ID: References: <84mxxbknma.fsf@cs.bham.ac.uk> Date: Sat, 10 Apr 2010 22:54:44 -0400 In-Reply-To: <84mxxbknma.fsf@cs.bham.ac.uk> (Uday S. Reddy's message of "Sat, 10 Apr 2010 22:23:57 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 5924 Cc: 5924@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > Reading the elisp manual doesn't indicate anywhere that a call such as > (accept-process-output process) > should change the current-buffer. That depends on the code run during the wait. I.e. it depends on the code run by the process filters, sentinels, timers, ... We've already fixed several bugs where process filters changed current-buffer, but I think we should fix it not in the process filters but in the code that run them. At least, unless someone can come up with a scenario where a process filter, sentinel, or timer would need to change current-buffer. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 11 08:22:42 2010 Received: (at 5924) by debbugs.gnu.org; 11 Apr 2010 12:22:42 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0wBW-00032D-05 for submit@debbugs.gnu.org; Sun, 11 Apr 2010 08:22:42 -0400 Received: from sun60.bham.ac.uk ([147.188.128.137]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0wBU-000328-1t for 5924@debbugs.gnu.org; Sun, 11 Apr 2010 08:22:40 -0400 Received: from [147.188.128.127] (helo=bham.ac.uk) by sun60.bham.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1O0wBN-0003K0-PI; Sun, 11 Apr 2010 13:22:33 +0100 Received: from mx1.cs.bham.ac.uk ([147.188.192.53]) by bham.ac.uk with esmtp (Exim 4.43) id 1O0wBN-0002Ow-FP; Sun, 11 Apr 2010 13:22:33 +0100 Received: from gromit.cs.bham.ac.uk ([147.188.193.16] helo=MARUTI.cs.bham.ac.uk) by mx1.cs.bham.ac.uk with esmtp (Exim 4.51) id 1O0wBN-00008p-Ga; Sun, 11 Apr 2010 13:22:33 +0100 Message-ID: <19393.48894.735000.238546@gargle.gargle.HOWL> Date: Sun, 11 Apr 2010 13:22:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Uday S Reddy To: Stefan Monnier Subject: Re: bug#5924: 23.1; accept-process-output switching current-buffer In-Reply-To: References: <84mxxbknma.fsf@cs.bham.ac.uk> X-Mailer: VM 8.2.0-devo under 23.1.1 (i386-mingw-nt5.1.2600) X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 5924 Cc: Uday S Reddy , 5924@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) Stefan Monnier writes: > > Reading the elisp manual doesn't indicate anywhere that a call such as > > (accept-process-output process) > > should change the current-buffer. > > That depends on the code run during the wait. I.e. it depends on the > code run by the process filters, sentinels, timers, ... Yes, indeed! If there is code being run during accept-process-output then the state can be changed by that code. But in the example that I witnessed, there was *no code* being run. Looking at the manual again, it says in "Accepting Output from Processes": "There are *two ways* to receive the output that a subprocess writes to its standard output stream. The output can be inserted in a buffer, which is called the associated buffer of the process, or a function called the "filter function" can be called to act on the output." In the second "way" that is being talked about, we can reasonably expect that current-buffer might change during the execution of the filter function. But in the first "way", where Emacs is doing all the work of accepting the process output, I don't think it should change the current-buffer. > We've already fixed several bugs where process filters changed > current-buffer, but I think we should fix it not in the process filters > but in the code that run them. At least, unless someone can come up > with a scenario where a process filter, sentinel, or timer would need > to change current-buffer. I don't fully understand this, but let me say that I am just talking about problem with the Elisp semantics, not Emacs libraries. If a filter function changed the current-buffer, one would regard it as buggy. But if Elisp itself changes the current-buffer...? The other thing that concerns me is that the same behaviour persisted even if I set the JUST-THIS-ONE flag to t. In that case, one would expect that Elisp would ignore the output from all other processes. So, it should have no reason to change the current-buffer to the other process. But it did. I am not sure if the JUST-THIS-ONE flag is doing anything at all. Cheers, Uday PS I have been looking at the emacs-developers list lately. It is quite amazing how much the guys talk, RMS included! From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 11 12:30:58 2010 Received: (at 5924) by debbugs.gnu.org; 11 Apr 2010 16:30:58 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O103m-0004j5-Dz for submit@debbugs.gnu.org; Sun, 11 Apr 2010 12:30:58 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O103j-0004iz-Gr for 5924@debbugs.gnu.org; Sun, 11 Apr 2010 12:30:56 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF+WwUtMCqWu/2dsb2JhbACbRXK2AoUMBItGgwI X-IronPort-AV: E=Sophos;i="4.52,185,1270440000"; d="scan'208";a="60626230" Received: from 76-10-165-174.dsl.teksavvy.com (HELO pastel.home) ([76.10.165.174]) by ironport2-out.pppoe.ca with ESMTP; 11 Apr 2010 12:30:48 -0400 Received: by pastel.home (Postfix, from userid 20848) id 4253E7F1B; Sun, 11 Apr 2010 12:30:48 -0400 (EDT) From: Stefan Monnier To: Uday S Reddy Subject: Re: bug#5924: 23.1; accept-process-output switching current-buffer Message-ID: References: <84mxxbknma.fsf@cs.bham.ac.uk> <19393.48894.735000.238546@gargle.gargle.HOWL> Date: Sun, 11 Apr 2010 12:30:48 -0400 In-Reply-To: <19393.48894.735000.238546@gargle.gargle.HOWL> (Uday S. Reddy's message of "Sun, 11 Apr 2010 13:22:22 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 5924 Cc: 5924@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) >> > Reading the elisp manual doesn't indicate anywhere that a call such as >> > (accept-process-output process) >> > should change the current-buffer. >> That depends on the code run during the wait. I.e. it depends on the >> code run by the process filters, sentinels, timers, ... > Yes, indeed! If there is code being run during accept-process-output > then the state can be changed by that code. But in the example that I > witnessed, there was *no code* being run. That's very odd: both the sentinel and the filter code are careful to preserve the current_buffer when there's no sentinel or no filter set. I've just installed a change in the Emacs Bzr trunk so that the current-buffer is preserved when running the Elisp code of process filters and sentinels. If you can try this code (or try the patch below) to see if it fixes your problem, it would be helpful. > In the second "way" that is being talked about, we can reasonably > expect that current-buffer might change during the execution of the > filter function. But in the first "way", where Emacs is doing all the > work of accepting the process output, I don't think it should change > the current-buffer. Indeed and it shouldn't. And with my new changes, even when running Elisp it shouldn't change current-buffer either. > I don't fully understand this, but let me say that I am just talking > about problem with the Elisp semantics, not Emacs libraries. If a > filter function changed the current-buffer, one would regard it as > buggy. But if Elisp itself changes the current-buffer...? Given that it's code run asynchronously, letting it change current-buffer is asking for trouble. > The other thing that concerns me is that the same behaviour persisted > even if I set the JUST-THIS-ONE flag to t. In that case, one would > expect that Elisp would ignore the output from all other processes. Indeed, that's what it means. > So, it should have no reason to change the current-buffer to the other > process. But it did. I am not sure if the JUST-THIS-ONE flag is > doing anything at all. I don't know of a bug in this regard, so if you have evidence that JUST-THIS-ONE doesn't prevent reading other process's output, please report it. Stefan === modified file 'src/process.c' --- src/process.c 2010-04-02 03:10:33 +0000 +++ src/process.c 2010-04-11 16:15:09 +0000 @@ -5314,6 +5314,8 @@ struct coding_system *coding = proc_decode_coding_system[channel]; int carryover = p->decoding_carryover; int readmax = 4096; + int count = SPECPDL_INDEX (); + Lisp_Object odeactivate; chars = (char *) alloca (carryover + readmax); if (carryover) @@ -5386,15 +5388,16 @@ /* Now set NBYTES how many bytes we must decode. */ nbytes += carryover; + odeactivate = Vdeactivate_mark; + /* There's no good reason to let process filters change the current + buffer, and many callers of accept-process-output, sit-for, and + friends don't expect current-buffer to be changed from under them. */ + record_unwind_protect (Fset_buffer, Fcurrent_buffer ()); + /* Read and dispose of the process output. */ outstream = p->filter; if (!NILP (outstream)) { - /* We inhibit quit here instead of just catching it so that - hitting ^G when a filter happens to be running won't screw - it up. */ - int count = SPECPDL_INDEX (); - Lisp_Object odeactivate; Lisp_Object obuffer, okeymap; Lisp_Object text; int outer_running_asynch_code = running_asynch_code; @@ -5402,10 +5405,12 @@ /* No need to gcpro these, because all we do with them later is test them for EQness, and none of them should be a string. */ - odeactivate = Vdeactivate_mark; XSETBUFFER (obuffer, current_buffer); okeymap = current_buffer->keymap; + /* We inhibit quit here instead of just catching it so that + hitting ^G when a filter happens to be running won't screw + it up. */ specbind (Qinhibit_quit, Qt); specbind (Qlast_nonmenu_event, Qt); @@ -5474,9 +5479,6 @@ restore_search_regs (); running_asynch_code = outer_running_asynch_code; - /* Handling the process output should not deactivate the mark. */ - Vdeactivate_mark = odeactivate; - /* Restore waiting_for_user_input_p as it was when we were called, in case the filter clobbered it. */ waiting_for_user_input_p = waiting; @@ -5492,27 +5494,19 @@ cause trouble (for example it would make sit_for return). */ if (waiting_for_user_input_p == -1) record_asynch_buffer_change (); - - unbind_to (count, Qnil); - return nbytes; } /* If no filter, write into buffer if it isn't dead. */ - if (!NILP (p->buffer) && !NILP (XBUFFER (p->buffer)->name)) + else if (!NILP (p->buffer) && !NILP (XBUFFER (p->buffer)->name)) { Lisp_Object old_read_only; int old_begv, old_zv; int old_begv_byte, old_zv_byte; - Lisp_Object odeactivate; int before, before_byte; int opoint_byte; Lisp_Object text; struct buffer *b; - int count = SPECPDL_INDEX (); - odeactivate = Vdeactivate_mark; - - record_unwind_protect (Fset_buffer, Fcurrent_buffer ()); Fset_buffer (p->buffer); opoint = PT; opoint_byte = PT_BYTE; @@ -5610,13 +5604,14 @@ if (old_begv != BEGV || old_zv != ZV) Fnarrow_to_region (make_number (old_begv), make_number (old_zv)); - /* Handling the process output should not deactivate the mark. */ - Vdeactivate_mark = odeactivate; current_buffer->read_only = old_read_only; SET_PT_BOTH (opoint, opoint_byte); - unbind_to (count, Qnil); } + /* Handling the process output should not deactivate the mark. */ + Vdeactivate_mark = odeactivate; + + unbind_to (count, Qnil); return nbytes; } @@ -6845,6 +6840,11 @@ XSETBUFFER (obuffer, current_buffer); okeymap = current_buffer->keymap; + /* There's no good reason to let sentinels change the current + buffer, and many callers of accept-process-output, sit-for, and + friends don't expect current-buffer to be changed from under them. */ + record_unwind_protect (Fset_buffer, Fcurrent_buffer ()); + sentinel = p->sentinel; if (NILP (sentinel)) return; From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 11 18:47:56 2010 Received: (at 5924) by debbugs.gnu.org; 11 Apr 2010 22:47:56 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O15wa-0007Dt-Hw for submit@debbugs.gnu.org; Sun, 11 Apr 2010 18:47:56 -0400 Received: from smtprelay-h11.telenor.se ([62.127.194.4]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O15wY-0007Do-B6 for 5924@debbugs.gnu.org; Sun, 11 Apr 2010 18:47:55 -0400 Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-h11.telenor.se (Postfix) with ESMTP id 8B100F045 for <5924@debbugs.gnu.org>; Mon, 12 Apr 2010 00:47:50 +0200 (CEST) X-SENDER-IP: [85.228.207.24] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am5AAEPuwUtV5M8YPGdsb2JhbACHZIgOi1IMAQEBATUttWOFDAQ X-IronPort-AV: E=Sophos;i="4.52,186,1270418400"; d="scan'208";a="62153886" Received: from c-18cfe455.04-211-6c6b701.cust.bredbandsbolaget.se (HELO muon.localdomain) ([85.228.207.24]) by ipb1.telenor.se with ESMTP; 12 Apr 2010 00:47:49 +0200 Received: by muon.localdomain (Postfix, from userid 1000) id 2C28348425D; Mon, 12 Apr 2010 00:47:48 +0200 (CEST) From: bojohan@gnu.org (Johan =?utf-8?Q?Bockg=C3=A5rd?=) To: 5924@debbugs.gnu.org Subject: Re: bug#5924: 23.1; accept-process-output switching current-buffer References: <84mxxbknma.fsf@cs.bham.ac.uk> <19393.48894.735000.238546@gargle.gargle.HOWL> Mail-Copies-To: never Date: Mon, 12 Apr 2010 00:47:47 +0200 In-Reply-To: (Stefan Monnier's message of "Sun, 11 Apr 2010 12:30:48 -0400") Message-ID: <87vdbxli7g.fsf@gnu.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.3 (----) X-Debbugs-Envelope-To: 5924 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.5 (---) Stefan Monnier writes: > + /* There's no good reason to let sentinels change the current > + buffer, and many callers of accept-process-output, sit-for, and > + friends don't expect current-buffer to be changed from under them. */ > + record_unwind_protect (Fset_buffer, Fcurrent_buffer ()); set_buffer_if_live? From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 12 15:13:43 2010 Received: (at 5924) by debbugs.gnu.org; 12 Apr 2010 19:13:43 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1P4o-0001Qt-Dc for submit@debbugs.gnu.org; Mon, 12 Apr 2010 15:13:43 -0400 Received: from sun61.bham.ac.uk ([147.188.128.150]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1P4m-0001Qo-H9 for 5924@debbugs.gnu.org; Mon, 12 Apr 2010 15:13:41 -0400 Received: from [147.188.128.127] (helo=bham.ac.uk) by sun61.bham.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1O1P4g-0004Kn-Ni; Mon, 12 Apr 2010 20:13:34 +0100 Received: from mx1.cs.bham.ac.uk ([147.188.192.53]) by bham.ac.uk with esmtp (Exim 4.43) id 1O1P4g-0006nc-Dq; Mon, 12 Apr 2010 20:13:34 +0100 Received: from gromit.cs.bham.ac.uk ([147.188.193.16] helo=MARUTI.cs.bham.ac.uk) by mx1.cs.bham.ac.uk with esmtp (Exim 4.51) id 1O1P4g-0002y1-5x; Mon, 12 Apr 2010 20:13:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19395.28879.546000.627509@gargle.gargle.HOWL> Date: Mon, 12 Apr 2010 20:13:19 +0100 From: Uday S Reddy To: Stefan Monnier Subject: Re: bug#5924: 23.1; accept-process-output switching current-buffer In-Reply-To: References: <84mxxbknma.fsf@cs.bham.ac.uk> <19393.48894.735000.238546@gargle.gargle.HOWL> X-Mailer: VM 8.2.0-devo under 22.2.1 (i386-mingw-nt5.1.2600) X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 5924 Cc: Uday S Reddy , 5924@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.2 (---) Stefan Monnier writes: > I've just installed a change in the Emacs Bzr trunk so that the > current-buffer is preserved when running the Elisp code of process > filters and sentinels. If you can try this code (or try the patch > below) to see if it fixes your problem, it would be helpful. Hi Stephan, thanks very much for the quick action on this. I am a bit embarrassed because I have never done a build of Emacs. And, I am going to be away for a few days. So, it will take me a while to try it out. Hope you don't mind. The trick I use for these kinds of asynchronous errors is to set error traps that log entries whenever the unexpected situations occur. Of course, it is not easy to figure out what to log and several repeated trials may be necessary to get enough diagnostic information. > > So, it should have no reason to change the current-buffer to the other > > process. But it did. I am not sure if the JUST-THIS-ONE flag is > > doing anything at all. > > I don't know of a bug in this regard, so if you have evidence that > JUST-THIS-ONE doesn't prevent reading other process's output, please > report it. OK, I defined a wrappe around accept-process-output function as follows: (defsubst vm-accept-process-output (process) (let ((buf (current-buffer)) (old-point-max (save-excursion (switch-to-buffer candidate-buf) (point-max)))) (accept-process-output process nil nil t) (if (not (equal buf (current-buffer))) (if (and (equal (current-buffer) candidate-buf) (not (= old-point-max (point-max)))) (debug "found output sent to %s: %s to %s" (current-buffer) old-point-max (point-max)) (debug "found buffer changed to %s" (current-buffer)))))) Since the JUST-THIS-ONE flag is passed in as t, it shouldn't insert anything anything in 'candidate-buf' (which was my guess as to where it would go). But the backtrace shows that it went there. Debugger entered: ("found output sent to %s: %s to %s" # 1019 1086) vm-imap-read-object(#>) vm-imap-read-response(#>) vm-imap-read-response-and-verify(#> "size FETCH") vm-imap-get-message-size(#> 3698) byte-code(...) vm-imap-synchronize-folder(t nil t t t t) vm-get-spooled-mail(t) vm-get-new-mail(nil) call-interactively(vm-get-new-mail nil nil) Cheers, Uday From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 12 15:39:33 2010 Received: (at 5924) by debbugs.gnu.org; 12 Apr 2010 19:39:33 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1PTp-0001h6-Be for submit@debbugs.gnu.org; Mon, 12 Apr 2010 15:39:33 -0400 Received: from sun61.bham.ac.uk ([147.188.128.150]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1PTn-0001h1-FH for 5924@debbugs.gnu.org; Mon, 12 Apr 2010 15:39:32 -0400 Received: from [147.188.128.127] (helo=bham.ac.uk) by sun61.bham.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1O1PTh-0004o3-NE; Mon, 12 Apr 2010 20:39:25 +0100 Received: from mx1.cs.bham.ac.uk ([147.188.192.53]) by bham.ac.uk with esmtp (Exim 4.43) id 1O1PTh-00015U-DL; Mon, 12 Apr 2010 20:39:25 +0100 Received: from gromit.cs.bham.ac.uk ([147.188.193.16] helo=MARUTI.cs.bham.ac.uk) by mx1.cs.bham.ac.uk with esmtp (Exim 4.51) id 1O1PTh-00036S-8D; Mon, 12 Apr 2010 20:39:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19395.30430.156000.1184@gargle.gargle.HOWL> Date: Mon, 12 Apr 2010 20:39:10 +0100 From: Uday S Reddy To: Stefan Monnier Subject: Re: bug#5924: 23.1; accept-process-output switching current-buffer In-Reply-To: References: <84mxxbknma.fsf@cs.bham.ac.uk> <19393.48894.735000.238546@gargle.gargle.HOWL> X-Mailer: VM 8.2.0-devo under 22.2.1 (i386-mingw-nt5.1.2600) X-Spam-Score: -3.2 (---) X-Debbugs-Envelope-To: 5924 Cc: Uday S Reddy , 5924@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.2 (---) Stefan Monnier writes: > That's very odd: both the sentinel and the filter code are careful to > preserve the current_buffer when there's no sentinel or no filter set. I might also mention that the processes I am dealing with are created by open-network-stream. Perhaps this primitive is creating filters/sentinels which are creating interference. You can find my full code at the URL below if you want to check further. http://bazaar.launchpad.net/~vm/vm/trunk/annotate/head:/lisp/vm-imap.el The comment blocks give the signatures of the functions which you can use to perhaps locate the interesting bits. ---- I also realized lately that in the normal operation of VM, this problem doesn't show up much because it is rare to deal with multiple IMAP sessions concurrently. However, for the sake of development work, I have turned on tracing/logging, which is preserving the old process-buffers. So, this problem, which is luckily repeatable, occurs immediately after one IMAP session has been closed and another begun, because the IMAP server sends some random closing message to the old session while the new session is going on, and we get the interference that I have observed. Cheers, Uday From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 12 16:58:20 2010 Received: (at 5924) by debbugs.gnu.org; 12 Apr 2010 20:58:20 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1Qi4-0002GV-EK for submit@debbugs.gnu.org; Mon, 12 Apr 2010 16:58:20 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1Qi2-0002GQ-AO for 5924@debbugs.gnu.org; Mon, 12 Apr 2010 16:58:18 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPolw0tMCqWu/2dsb2JhbACbOnK9LYUMBItGgwI X-IronPort-AV: E=Sophos;i="4.52,192,1270440000"; d="scan'208";a="60707205" Received: from 76-10-165-174.dsl.teksavvy.com (HELO pastel.home) ([76.10.165.174]) by ironport2-out.pppoe.ca with ESMTP; 12 Apr 2010 16:58:13 -0400 Received: by pastel.home (Postfix, from userid 20848) id 710B37F1B; Mon, 12 Apr 2010 16:58:13 -0400 (EDT) From: Stefan Monnier To: Uday S Reddy Subject: Re: bug#5924: 23.1; accept-process-output switching current-buffer Message-ID: References: <84mxxbknma.fsf@cs.bham.ac.uk> <19393.48894.735000.238546@gargle.gargle.HOWL> <19395.28879.546000.627509@gargle.gargle.HOWL> Date: Mon, 12 Apr 2010 16:58:13 -0400 In-Reply-To: <19395.28879.546000.627509@gargle.gargle.HOWL> (Uday S. Reddy's message of "Mon, 12 Apr 2010 20:13:19 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 5924 Cc: 5924@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) >> I've just installed a change in the Emacs Bzr trunk so that the >> current-buffer is preserved when running the Elisp code of process >> filters and sentinels. If you can try this code (or try the patch >> below) to see if it fixes your problem, it would be helpful. > Hi Stephan, thanks very much for the quick action on this. I am a bit > embarrassed because I have never done a build of Emacs. And, I am > going to be away for a few days. So, it will take me a while to try > it out. Hope you don't mind. No problem, of course. > (defsubst vm-accept-process-output (process) > (let ((buf (current-buffer)) > (old-point-max (save-excursion > (switch-to-buffer candidate-buf) > (point-max)))) > (accept-process-output process nil nil t) > (if (not (equal buf (current-buffer))) > (if (and (equal (current-buffer) candidate-buf) > (not (= old-point-max (point-max)))) > (debug "found output sent to %s: %s to %s" > (current-buffer) old-point-max (point-max)) > (debug "found buffer changed to %s" (current-buffer)))))) [ Side note: please, please, pretty please, don't use switch-to-buffer: the above code is not supposed to mess with windows, so you want to use `set-buffer' instead, and actually in this case (with-current-buffer candidate-buf (point-max)) is really the right way to write it since you do not need to save any point&mark but only the current buffer. ] > Since the JUST-THIS-ONE flag is passed in as t, it shouldn't insert > anything anything in 'candidate-buf' (which was my guess as to where > it would go). But the backtrace shows that it went there. Hmm... will have to dig into this one as well. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu May 20 05:50:36 2010 Received: (at 5924) by debbugs.gnu.org; 20 May 2010 09:50:36 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OF2Oh-0002xL-Jc for submit@debbugs.gnu.org; Thu, 20 May 2010 05:50:35 -0400 Received: from sun60.bham.ac.uk ([147.188.128.137]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OF2Of-0002xE-GK for 5924@debbugs.gnu.org; Thu, 20 May 2010 05:50:34 -0400 Received: from [147.188.128.127] (helo=bham.ac.uk) by sun60.bham.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1OF2Ob-00000o-Nz; Thu, 20 May 2010 10:50:29 +0100 Received: from mx1.cs.bham.ac.uk ([147.188.192.53]) by bham.ac.uk with esmtp (Exim 4.43) id 1OF2Ob-0005Lt-E0; Thu, 20 May 2010 10:50:29 +0100 Received: from gromit.cs.bham.ac.uk ([147.188.193.16] helo=gromit.cs.bham.ac.uk.cs.bham.ac.uk) by mx1.cs.bham.ac.uk with esmtp (Exim 4.51) id 1OF2Ob-000287-BJ; Thu, 20 May 2010 10:50:29 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="x1P+rHYNHQ" Content-Transfer-Encoding: 7bit Message-ID: <19445.1508.916983.573445@gromit.cs.bham.ac.uk> Date: Thu, 20 May 2010 10:50:28 +0100 From: Uday S Reddy To: Stefan Monnier Subject: Re: bug#5924: 23.1; accept-process-output switching current-buffer In-Reply-To: References: <84mxxbknma.fsf@cs.bham.ac.uk> <19393.48894.735000.238546@gargle.gargle.HOWL> X-Mailer: VM 8.1.90a under 22.2.1 (i686-pc-linux-gnu) X-Spam-Score: -1.0 (-) X-Debbugs-Envelope-To: 5924 Cc: Uday S Reddy , 5924@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.9 (/) --x1P+rHYNHQ Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: base64 U3RlZmFuIE1vbm5pZXIgd3JpdGVzOg0KDQo+IEkndmUganVzdCBpbnN0YWxsZWQgYSBjaGFuZ2Ug aW4gdGhlIEVtYWNzIEJ6ciB0cnVuayBzbyB0aGF0IHRoZQ0KPiBjdXJyZW50LWJ1ZmZlciBpcyBw cmVzZXJ2ZWQgd2hlbiBydW5uaW5nIHRoZSBFbGlzcCBjb2RlIG9mIHByb2Nlc3MNCj4gZmlsdGVy cyBhbmQgc2VudGluZWxzLiAgSWYgeW91IGNhbiB0cnkgdGhpcyBjb2RlIChvciB0cnkgdGhlIHBh dGNoDQo+IGJlbG93KSB0byBzZWUgaWYgaXQgZml4ZXMgeW91ciBwcm9ibGVtLCBpdCB3b3VsZCBi ZSBoZWxwZnVsLg0KDQpIaSBTdGVwaGFuLCBTb3JyeSBmb3IgdGhlIGRlbGF5IGluIGdldHRpbmcg YmFjayB0byB5b3UuICBJIGhhdmUgbm93DQpjb21waWxlZCBhbmQgdHJpZWQgdGhlIGxhdGVzdCBi enIgdmVyc2lvbiAocmV2bm8gMTAwMzY4KS4gIEJ1dCwgaXQNCnNlZW1zIHRvIHRoYXQgdGhlIHBy b2JsZW0gcGVyc2lzdHMuDQoNCkhlcmUgaXMgbXkgY3VycmVudCBwcm94eSBmb3IgYWNjZXB0LXBy b2Nlc3Mtb3V0cHV0Og0KDQogIChkZWZzdWJzdCB2bS1hY2NlcHQtcHJvY2Vzcy1vdXRwdXQgKHBy b2Nlc3MpDQogICAgIkFjY2VwdCBvdXRwdXQgZnJvbSBQUk9DRVNTLiAgVGhlIHZhcmlhYmxlIGB2 bS1pbWFwLXNlcnZlci10aW1lb3V0Jw0KICBzcGVjaWZpZXMgaG93IG1hbnkgc2Vjb25kcyB0byB3 YWl0IGJlZm9yZSB0aW1pbmcgb3V0LiAgSWYgYSB0aW1lb3V0DQogIG9jY3VycywgdHlwaWNhbGx5 IFZNIGNhbm5vdCBwcm9jZWVkLiINCiAgICA7OyBwcm90ZWN0IGFnYWluc3QgcG9zc2libGUgYnVm ZmVyIGNoYW5nZSBkdWUgdG8gYnVnIGluIEVtYWNzDQogICAgKGxldCAoKGJ1ZiAoY3VycmVudC1i dWZmZXIpKQ0KCSAgKGdvdC1vdXRwdXQgKGFjY2VwdC1wcm9jZXNzLW91dHB1dCBwcm9jZXNzIHZt LWltYXAtc2VydmVyLXRpbWVvdXQpKSkNCiAgICAgIChpZiBnb3Qtb3V0cHV0DQoJICAod2hlbiAo bm90IChlcXVhbCAoY3VycmVudC1idWZmZXIpIGJ1ZikpDQoJICAgIChpZiAoc3RyaW5nLWxlc3Nw ICIyNCIgZW1hY3MtdmVyc2lvbikNCgkJOzsgdGhlIEVtYWNzIGJ1ZyBzaG91bGQgaGF2ZSBiZWVu IGZpeGVkDQoJCShtZXNzYWdlIA0KCQkgIkVtYWNzIHByb2Nlc3Mgb3V0cHV0IGVycm9yOiBCdWZm ZXIgY2hhbmdlZCB0byAlcyIgDQoJCSAoY3VycmVudC1idWZmZXIpKSkNCgkgICAgOzsgcmVjb3Zl ciBmcm9tIHRoZSBidWcNCgkgICAgKHNldC1idWZmZXIgYnVmKSkNCgkodm0taW1hcC1wcm90b2Nv bC1lcnJvciAiTm8gcmVzcG9uc2UgZnJvbSB0aGUgSU1BUCBzZXJ2ZXIiKSkpKQ0KDQphbmQgdGhl IGVycm9yIGNhbWUgdXAgcHJldHR5IG11Y2ggdGhlIGZpcnN0IHRpbWUgSSB0cmllZCBpdDoNCg0K ICBFbWFjcyBwcm9jZXNzIG91dHB1dCBlcnJvcjogQnVmZmVyIGNoYW5nZWQgdG8gc2F2ZWQgSU1B UCBtYWlsaG9zdC5jIDEwOjMxOjA5DQoNClRoZSBjdXJyZW50LWJ1ZmZlciBzaG91bGQgaGF2ZSBi ZWVuICJJTUFQIG1haWxob3N0LmMgMTA6MzEuNDAiLiAgQnV0DQppdCBzd2l0Y2hlZCB0byB0aGUg IklNQVAgbWFpbGhvc3QuYyAxMDozMTowOSIgKGNhbGwgaXQgdGhlICJvbGQNCmJ1ZmZlciIpIGJl Y2F1c2UgaXRzIHByb2Nlc3Mgc2VudCBzb21lIG91dHB1dC4NCg0KSSBhbSBhdHRhY2hpbmcgdGhl IGNvbnRlbnRzIG9mIHRoZSBvbGQgYnVmZmVyLiAgSSB0aGluayB0aGUgbGFzdCBsaW5lDQp3b3Vs ZCBoYXZlIGJlZW4gb3V0cHV0IHdoaWxlIHRoZSBjdXJyZW50IGFjY2VwdC1wcm9jZXNzLW91dHB1 dCB3YXMNCmRvbmUuICAoTm90ZSB0aGF0IHRoaXMgbGluZSBjYW1lIGluIGEgZmV3IHNlY29uZHMg YWZ0ZXIgdGhlIGN1cnJlbnQNCnByb2Nlc3MgZ290IHN0YXJ0ZWQuKQ0KDQpTbywgdGhlcmUgYXBw ZWFycyB0byBiZSBzb21lIGRlZXBlciBwcm9ibGVtIHRoYW4gb3JpZ2luYWxseSB0aG91Z2h0Lg0K DQpDaGVlcnMsDQpVZGF5DQoNCjNSaGNuUnBibWNnU1UxQlVDQnpaWE56YVc5dUlGUm9kU0JOWVhr Z01qQWdNVEE2TXpFNk1Ea2dNakF4TUEwS1kyOXVibVZqZEdsdQ0KWnlCMGJ5QnRZV2xzYUc5emRD NWpjeTVpYUdGdExtRmpMblZyT2pFME13MEtZMjl1Ym1WamRHVmtJR1p2Y2lCbVpYUmphQTBLS2lC UA0KU3lCSlRVRlFOQ0JTWldGa2VTQnBiV0Z3SURBd01ERmpaR1l6RFEwS1ZrMGdRMEZRUVVKSlRF bFVXUTBOQ2lvZ1EwRlFRVUpKVEVsVQ0KV1NCSlRVRlFOQ0JKVFVGUU5GSkZWakVORFFwV1RTQlBT eUJEUVZCQlFrbE1TVlJaRFEwS1ZrMGdURTlIU1U0Z1BIQmhjbUZ0WlhSbA0KY25NZ2IyMXBkSFJs WkQ0TkRRcFdUU0JQU3lCTWIyZG5aV1FnYVc0dURRMEtWazBnVTBWTVJVTlVJQ0pKVGtKUFdDSU5E UW9xSUVaTQ0KUVVkVElDaGNRVzV6ZDJWeVpXUWdYRVpzWVdkblpXUWdYRVJsYkdWMFpXUWdYRk5s Wlc0Z1hFUnlZV1owSUdadmNuZGhjbVJsWkNCbQ0KYVd4bFpDQnlaV1JwYzNSeWFXSjFkR1ZrSUNF Z0pFWnZjbmRoY21SbFpDQTNNelV3SURjek5UUWdOek01TVNCemFXZHVaV1FnS2lCaA0KWTJObGNI UWdZV04wYVc5dUlIQnNZV2RwWVhKcGMyMGdTblZ1YXlCT2IyNUtkVzVySUNGQUtRME5DaW9nVDBz Z1cxQkZVazFCVGtWTw0KVkVaTVFVZFRJQ2hjUVc1emQyVnlaV1FnWEVac1lXZG5aV1FnWEVSbGJH VjBaV1FnWEZObFpXNGdYRVJ5WVdaMElHWnZjbmRoY21SbA0KWkNCbWFXeGxaQ0J5WldScGMzUnlh V0oxZEdWa0lDRWdKRVp2Y25kaGNtUmxaQ0EzTXpVd0lEY3pOVFFnTnpNNU1TQnphV2R1WldRZw0K S2lCaFkyTmxjSFFnWVdOMGFXOXVJSEJzWVdkcFlYSnBjMjBnU25WdWF5Qk9iMjVLZFc1cklDRkFJ RndxS1YwZ1JteGhaM01nY0dWeQ0KYldsMGRHVmtMZzBOQ2lvZ01qWTBPQ0JGV0VsVFZGTU5EUW9x SURBZ1VrVkRSVTVVRFEwS0tpQlBTeUJiVlVsRVZrRk1TVVJKVkZrZw0KTVRJeE56STBNekUwTmww Z1ZVbEVjeUIyWVd4cFpBME5DaW9nVDBzZ1cxVkpSRTVGV0ZRZ01qWTJNREJkSUZCeVpXUnBZM1Js WkNCdQ0KWlhoMElGVkpSQTBOQ2xaTklFOUxJRnRTUlVGRUxWZFNTVlJGWFNCVFpXeGxZM1FnWTI5 dGNHeGxkR1ZrTGcwTkNsWk5JRlZKUkNCRw0KUlZSRFNDQXlOalEzTVRveU5qUTNNU0FvVWtaRE9E SXlMbE5KV2tVcERRMEtLaUF5TlRrMElFWkZWRU5JSUNoU1JrTTRNakl1VTBsYQ0KUlNBMU9ERTNO U0JWU1VRZ01qWTBOekVwRFEwS1ZrMGdUMHNnUm1WMFkyZ2dZMjl0Y0d4bGRHVmtMZzBOQ2xaTklG VkpSQ0JHUlZSRA0KU0NBeU5qUTNNVG95TmpRM01TQW9RazlFV1M1UVJVVkxXMTBwRFEwS0tpQXlO VGswSUVaRlZFTklJQ2hWU1VRZ01qWTBOekVnUWs5RQ0KV1Z0ZElIczFPREUzTlgwTkRRb3BEUTBL VmswZ1Qwc2dSbVYwWTJnZ1kyOXRjR3hsZEdWa0xnME5DbFpOSUU1UFQxQU5EUXBXVFNCUA0KU3lC T1QwOVFJR052YlhCc1pYUmxaQzRORFFwV1RTQlZTVVFnUmtWVVEwZ2dNalkxT0RJNk1qWTFPREln S0ZKR1F6Z3lNaTVUU1ZwRg0KS1EwTkNpb2dNall6T0NCR1JWUkRTQ0FvVWtaRE9ESXlMbE5KV2tV Z01qRTRNU0JWU1VRZ01qWTFPRElwRFEwS1ZrMGdUMHNnUm1WMA0KWTJnZ1kyOXRjR3hsZEdWa0xn ME5DbFpOSUZWSlJDQkdSVlJEU0NBeU5qVTRNam95TmpVNE1pQW9RazlFV1M1UVJVVkxXMTBwRFEw Sw0KS2lBeU5qTTRJRVpGVkVOSUlDaFZTVVFnTWpZMU9ESWdRazlFV1Z0ZElIc3lNVGd4ZlEwTkNp a05EUXBXVFNCUFN5QkdaWFJqYUNCag0KYjIxd2JHVjBaV1F1RFEwS1ZrMGdUazlQVUEwTkNsWk5J RTlMSUU1UFQxQWdZMjl0Y0d4bGRHVmtMZzBOQ2xaTklGVkpSQ0JHUlZSRA0KU0NBeU5qUTNNVG95 TmpRM01TQW9Va1pET0RJeUxsTkpXa1VwRFEwS0tpQXlOVGswSUVaRlZFTklJQ2hTUmtNNE1qSXVV MGxhUlNBMQ0KT0RFM05TQlZTVVFnTWpZME56RXBEUTBLVmswZ1QgMHNnUm1WMFkyZ2dZMjl0Y0d4 bGRHVmtMZzBOQ2xaTklGVkpSQ0JHUlZSRFNDQXkNCk5qUTNNVG95TmpRM01TQW9RazlFV1M1UVJV VkxXMTBwRFEwS0tpQXlOVGswSUVaRlZFTklJQ2hWU1VRZ01qWTBOekVnUWs5RVdWdGQNCklIczFP REUzTlgwTkRRb3BEUTBLVmswZ1Qwc2dSbVYwWTJnZ1kyOXRjR3hsZEdWa0xnME5DbFpOSUU1UFQx QU5EUXBXVFNCUFN5Qk8NClQwOVFJR052YlhCc1pYUmxaQzRORFFwV1RTQlZTVVFnUmtWVVEwZ2dN alkxTnpnNk1qWTFOemdnS0ZKR1F6Z3lNaTVUU1ZwRktRME4NCkNpb2dNall6TlNCR1JWUkRTQ0Fv VWtaRE9ESXlMbE5KV2tVZ05USXpPRGdnVlVsRUlESTJOVGM0S1EwTkNsWk5JRTlMSUVabGRHTm8N CklHTnZiWEJzWlhSbFpDNE5EUXBXVFNCVlNVUWdSa1ZVUTBnZ01qWTFOemc2TWpZMU56Z2dLRUpQ UkZrdVVFVkZTMXRkS1EwTkNpb2cNCk1qWXpOU0JHUlZSRFNDQW9WVWxFSURJMk5UYzRJRUpQUkZs YlhTQjdOVEl6T0RoOURRMEtLUTBOQ2xaTklFOUxJRVpsZEdOb0lHTnYNCmJYQnNaWFJsWkM0TkRR cFdUU0JNVDBkUFZWUU5EUW9xSUVKWlJTQk1iMmRuYVc1bklHOTFkQTBOQ2xaTklFOUxJRXh2WjI5 MWRDQmoNCmIyMXdiR1YwWldRdURRMEtEUXBRY205alpYTnpJRWxOUVZBOE1qNGdZMjl1Ym1WamRH bHZiaUJpY205clpXNGdZbmtnY21WdGIzUmwNCklIQmxaWElOQ21WdVpHbHVaeUJKVFVGUUlITmxj M05wYjI0Z1ZHaDFJRTFoZVNBeU1DQXhNRG96TVRvME15QXlNREV3DQ== --x1P+rHYNHQ Content-Type: text/plain; name="saved-IMAP-buffer.txt" Content-Description: contents of IMAP mailhost.c 10:31:09 Content-Disposition: inline; filename="saved-IMAP-buffer.txt" Content-Transfer-Encoding: base64 c3RhcnRpbmcgSU1BUCBzZXNzaW9uIFRodSBNYXkgMjAgMTA6MzE6MDkgMjAxMA0KY29ubmVjdGlu ZyB0byBtYWlsaG9zdC5jcy5iaGFtLmFjLnVrOjE0Mw0KY29ubmVjdGVkIGZvciBmZXRjaA0KKiBP SyBJTUFQNCBSZWFkeSBpbWFwIDAwMDFjZGYzDQ0KVk0gQ0FQQUJJTElUWQ0NCiogQ0FQQUJJTElU WSBJTUFQNCBJTUFQNFJFVjENDQpWTSBPSyBDQVBBQklMSVRZDQ0KVk0gTE9HSU4gPHBhcmFtZXRl cnMgb21pdHRlZD4NDQpWTSBPSyBMb2dnZWQgaW4uDQ0KVk0gU0VMRUNUICJJTkJPWCINDQoqIEZM QUdTIChcQW5zd2VyZWQgXEZsYWdnZWQgXERlbGV0ZWQgXFNlZW4gXERyYWZ0IGZvcndhcmRlZCBm aWxlZCByZWRpc3RyaWJ1dGVkICEgJEZvcndhcmRlZCA3MzUwIDczNTQgNzM5MSBzaWduZWQgKiBh Y2NlcHQgYWN0aW9uIHBsYWdpYXJpc20gSnVuayBOb25KdW5rICFAKQ0NCiogT0sgW1BFUk1BTkVO VEZMQUdTIChcQW5zd2VyZWQgXEZsYWdnZWQgXERlbGV0ZWQgXFNlZW4gXERyYWZ0IGZvcndhcmRl ZCBmaWxlZCByZWRpc3RyaWJ1dGVkICEgJEZvcndhcmRlZCA3MzUwIDczNTQgNzM5MSBzaWduZWQg KiBhY2NlcHQgYWN0aW9uIHBsYWdpYXJpc20gSnVuayBOb25KdW5rICFAIFwqKV0gRmxhZ3MgcGVy bWl0dGVkLg0NCiogMjY0OCBFWElTVFMNDQoqIDAgUkVDRU5UDQ0KKiBPSyBbVUlEVkFMSURJVFkg MTIxNzI0MzE0Nl0gVUlEcyB2YWxpZA0NCiogT0sgW1VJRE5FWFQgMjY2MDBdIFByZWRpY3RlZCBu ZXh0IFVJRA0NClZNIE9LIFtSRUFELVdSSVRFXSBTZWxlY3QgY29tcGxldGVkLg0NClZNIFVJRCBG RVRDSCAyNjQ3MToyNjQ3MSAoUkZDODIyLlNJWkUpDQ0KKiAyNTk0IEZFVENIIChSRkM4MjIuU0la RSA1ODE3NSBVSUQgMjY0NzEpDQ0KVk0gT0sgRmV0Y2ggY29tcGxldGVkLg0NClZNIFVJRCBGRVRD SCAyNjQ3MToyNjQ3MSAoQk9EWS5QRUVLW10pDQ0KKiAyNTk0IEZFVENIIChVSUQgMjY0NzEgQk9E WVtdIHs1ODE3NX0NDQopDQ0KVk0gT0sgRmV0Y2ggY29tcGxldGVkLg0NClZNIE5PT1ANDQpWTSBP SyBOT09QIGNvbXBsZXRlZC4NDQpWTSBVSUQgRkVUQ0ggMjY1ODI6MjY1ODIgKFJGQzgyMi5TSVpF KQ0NCiogMjYzOCBGRVRDSCAoUkZDODIyLlNJWkUgMjE4MSBVSUQgMjY1ODIpDQ0KVk0gT0sgRmV0 Y2ggY29tcGxldGVkLg0NClZNIFVJRCBGRVRDSCAyNjU4MjoyNjU4MiAoQk9EWS5QRUVLW10pDQ0K KiAyNjM4IEZFVENIIChVSUQgMjY1ODIgQk9EWVtdIHsyMTgxfQ0NCikNDQpWTSBPSyBGZXRjaCBj b21wbGV0ZWQuDQ0KVk0gTk9PUA0NClZNIE9LIE5PT1AgY29tcGxldGVkLg0NClZNIFVJRCBGRVRD SCAyNjQ3MToyNjQ3MSAoUkZDODIyLlNJWkUpDQ0KKiAyNTk0IEZFVENIIChSRkM4MjIuU0laRSA1 ODE3NSBVSUQgMjY0NzEpDQ0KVk0gT0sgRmV0Y2ggY29tcGxldGVkLg0NClZNIFVJRCBGRVRDSCAy NjQ3MToyNjQ3MSAoQk9EWS5QRUVLW10pDQ0KKiAyNTk0IEZFVENIIChVSUQgMjY0NzEgQk9EWVtd IHs1ODE3NX0NDQopDQ0KVk0gT0sgRmV0Y2ggY29tcGxldGVkLg0NClZNIE5PT1ANDQpWTSBPSyBO T09QIGNvbXBsZXRlZC4NDQpWTSBVSUQgRkVUQ0ggMjY1Nzg6MjY1NzggKFJGQzgyMi5TSVpFKQ0N CiogMjYzNSBGRVRDSCAoUkZDODIyLlNJWkUgNTIzODggVUlEIDI2NTc4KQ0NClZNIE9LIEZldGNo IGNvbXBsZXRlZC4NDQpWTSBVSUQgRkVUQ0ggMjY1Nzg6MjY1NzggKEJPRFkuUEVFS1tdKQ0NCiog MjYzNSBGRVRDSCAoVUlEIDI2NTc4IEJPRFlbXSB7NTIzODh9DQ0KKQ0NClZNIE9LIEZldGNoIGNv bXBsZXRlZC4NDQpWTSBMT0dPVVQNDQoqIEJZRSBMb2dnaW5nIG91dA0NClZNIE9LIExvZ291dCBj b21wbGV0ZWQuDQ0KDQpQcm9jZXNzIElNQVA8Mj4gY29ubmVjdGlvbiBicm9rZW4gYnkgcmVtb3Rl IHBlZXINCmVuZGluZyBJTUFQIHNlc3Npb24gVGh1IE1heSAyMCAxMDozMTo0MyAyMDEw --x1P+rHYNHQ-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 23 20:07:56 2010 Received: (at 5924) by debbugs.gnu.org; 24 May 2010 00:07:56 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGLD2-0003YU-5h for submit@debbugs.gnu.org; Sun, 23 May 2010 20:07:56 -0400 Received: from sun60.bham.ac.uk ([147.188.128.137]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGLD0-0003YP-Kc for 5924@debbugs.gnu.org; Sun, 23 May 2010 20:07:55 -0400 Received: from [147.188.128.127] (helo=bham.ac.uk) by sun60.bham.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1OGLCv-0002Ci-Nv; Mon, 24 May 2010 01:07:49 +0100 Received: from mx1.cs.bham.ac.uk ([147.188.192.53]) by bham.ac.uk with esmtp (Exim 4.43) id 1OGLCv-0007aJ-E0; Mon, 24 May 2010 01:07:49 +0100 Received: from gromit.cs.bham.ac.uk ([147.188.193.16] helo=MARUTI.cs.bham.ac.uk) by mx1.cs.bham.ac.uk with esmtp (Exim 4.51) id 1OGLCv-0003AQ-Ma; Mon, 24 May 2010 01:07:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19449.50009.338000.183687@gargle.gargle.HOWL> Date: Mon, 24 May 2010 01:07:53 +0100 From: Uday S Reddy To: Stefan Monnier Subject: Re: bug#5924: 23.1; accept-process-output switching current-buffer In-Reply-To: References: <84mxxbknma.fsf@cs.bham.ac.uk> <19393.48894.735000.238546@gargle.gargle.HOWL> X-Mailer: VM 8.1.90a under 23.2.1 (i386-mingw-nt5.1.2600) X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 5924 Cc: Uday S Reddy , 5924@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.7 (-) Dear Stefan, I have now tried this with the Windows build that was published today: emacs-20100523. The same problem occurs. (Of course, there was no reason to expect that anything would be different.) Even though I am able to protect the spurious buffer-change inside VM using my wrapper for accept-process-output, I can't do anything if some other process is invoked and the VM process interferes with it. This is now regularly occurring with smtpmail. In the middle of smtpmail, the buffer is changing to VM's IMAP process buffer (invoked for an FCC to an IMAP folder), and smtpmail fails. Sometimes the smtp has gone through and sometimes it hasn't. This is getting to be an annoyance. I am repeating my previous message again below, because it got MIME-encoded in a strange way last time: ---- Here is my current proxy for accept-process-output: (defsubst vm-accept-process-output (process) "Accept output from PROCESS. The variable `vm-imap-server-timeout' specifies how many seconds to wait before timing out. If a timeout occurs, typically VM cannot proceed." ;; protect against possible buffer change due to bug in Emacs (let ((buf (current-buffer)) (got-output (accept-process-output process vm-imap-server-timeout))) (if got-output (when (not (equal (current-buffer) buf)) (if (string-lessp "24" emacs-version) ;; the Emacs bug should have been fixed (message "Emacs process output error: Buffer changed to %s" (current-buffer))) ;; recover from the bug (set-buffer buf)) (vm-imap-protocol-error "No response from the IMAP server")))) and the error came up pretty much the first time I tried it: Emacs process output error: Buffer changed to saved IMAP mailhost.c 10:31:09 The current-buffer should have been "IMAP mailhost.c 10:31.40". But it switched to the "IMAP mailhost.c 10:31:09" (call it the "old buffer") because its process sent some output. I am attaching the contents of the old buffer. I think the last line would have been output while the current accept-process-output was done. (Note that this line came in a few seconds after the current process got started.) ----- starting IMAP session Thu May 20 10:31:09 2010 connecting to mailhost.cs.bham.ac.uk:143 connected for fetch * OK IMAP4 Ready imap 0001cdf3 VM CAPABILITY * CAPABILITY IMAP4 IMAP4REV1 VM OK CAPABILITY VM LOGIN VM OK Logged in. VM SELECT "INBOX" * FLAGS (\Answered \Flagged \Deleted \Seen \Draft forwarded filed redistributed ! $Forwarded 7350 7354 7391 signed * accept action plagiarism Junk NonJunk !@) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft forwarded filed redistributed ! $Forwarded 7350 7354 7391 signed * accept action plagiarism Junk NonJunk !@ \*)] Flags permitted. * 2648 EXISTS * 0 RECENT * OK [UIDVALIDITY 1217243146] UIDs valid * OK [UIDNEXT 26600] Predicted next UID VM OK [READ-WRITE] Select completed. VM UID FETCH 26471:26471 (RFC822.SIZE) * 2594 FETCH (RFC822.SIZE 58175 UID 26471) VM OK Fetch completed. VM UID FETCH 26471:26471 (BODY.PEEK[]) * 2594 FETCH (UID 26471 BODY[] {58175} ) VM OK Fetch completed. VM NOOP VM OK NOOP completed. VM UID FETCH 26582:26582 (RFC822.SIZE) * 2638 FETCH (RFC822.SIZE 2181 UID 26582) VM OK Fetch completed. VM UID FETCH 26582:26582 (BODY.PEEK[]) * 2638 FETCH (UID 26582 BODY[] {2181} ) VM OK Fetch completed. VM NOOP VM OK NOOP completed. VM UID FETCH 26471:26471 (RFC822.SIZE) * 2594 FETCH (RFC822.SIZE 58175 UID 26471) VM OK Fetch completed. VM UID FETCH 26471:26471 (BODY.PEEK[]) * 2594 FETCH (UID 26471 BODY[] {58175} ) VM OK Fetch completed. VM NOOP VM OK NOOP completed. VM UID FETCH 26578:26578 (RFC822.SIZE) * 2635 FETCH (RFC822.SIZE 52388 UID 26578) VM OK Fetch completed. VM UID FETCH 26578:26578 (BODY.PEEK[]) * 2635 FETCH (UID 26578 BODY[] {52388} ) VM OK Fetch completed. VM LOGOUT * BYE Logging out VM OK Logout completed. Process IMAP<2> connection broken by remote peer ending IMAP session Thu May 20 10:31:43 2010 --- Cheers, Uday From debbugs-submit-bounces@debbugs.gnu.org Sun May 23 22:04:58 2010 Received: (at 5924) by debbugs.gnu.org; 24 May 2010 02:04:58 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGN2I-0004Ik-Eu for submit@debbugs.gnu.org; Sun, 23 May 2010 22:04:58 -0400 Received: from sun61.bham.ac.uk ([147.188.128.150]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGN2G-0004If-Bv for 5924@debbugs.gnu.org; Sun, 23 May 2010 22:04:57 -0400 Received: from [147.188.128.127] (helo=bham.ac.uk) by sun61.bham.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1OGN2A-0007In-Np; Mon, 24 May 2010 03:04:50 +0100 Received: from mx1.cs.bham.ac.uk ([147.188.192.53]) by bham.ac.uk with esmtp (Exim 4.43) id 1OGN2A-0002aU-Dw; Mon, 24 May 2010 03:04:50 +0100 Received: from gromit.cs.bham.ac.uk ([147.188.193.16] helo=MARUTI.cs.bham.ac.uk) by mx1.cs.bham.ac.uk with esmtp (Exim 4.51) id 1OGN2A-0003MN-5s; Mon, 24 May 2010 03:04:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19449.57028.88000.501191@gargle.gargle.HOWL> Date: Mon, 24 May 2010 03:04:52 +0100 From: Uday S Reddy To: Stefan Monnier Subject: Re: bug#5924: 23.1; accept-process-output switching current-buffer In-Reply-To: References: <84mxxbknma.fsf@cs.bham.ac.uk> <19393.48894.735000.238546@gargle.gargle.HOWL> X-Mailer: VM 8.1.90a under 23.2.1 (i386-mingw-nt5.1.2600) X-Spam-Score: -1.7 (-) X-Debbugs-Envelope-To: 5924 Cc: Uday S Reddy , 5924@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.9 (--) Dear Stefan, I should take back my last couple of messages. I had a timer task running (after 2 second delay) which was changing buffers. Unfortunately, this was getting scheduled to run during the other process's accept-process-output. So, I had mistakenly put the blame on accept-process-output. This means that the reproducible version of the problem was due to my own misconfigured timer task. I will now go and hunt for the asynchronous versions of the problem to see if they are fixed by your patch. Sorry for the hassle. Cheers, Uday From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 23 18:37:05 2010 Received: (at 5924) by debbugs.gnu.org; 23 Jul 2010 22:37:05 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OcQrY-000817-LG for submit@debbugs.gnu.org; Fri, 23 Jul 2010 18:37:04 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OcQrW-0007zo-Hd for 5924@debbugs.gnu.org; Fri, 23 Jul 2010 18:37:03 -0400 Received: from ceviche.home (vpn-132-204-232-95.acd.umontreal.ca [132.204.232.95]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id o6NMalQC028140; Fri, 23 Jul 2010 18:36:48 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 80293660D2; Sat, 24 Jul 2010 00:36:46 +0200 (CEST) From: Stefan Monnier To: Uday S Reddy Subject: Re: bug#5924: 23.1; accept-process-output switching current-buffer Message-ID: References: <84mxxbknma.fsf@cs.bham.ac.uk> <19393.48894.735000.238546@gargle.gargle.HOWL> <19449.57028.88000.501191@gargle.gargle.HOWL> Date: Sat, 24 Jul 2010 00:36:46 +0200 In-Reply-To: <19449.57028.88000.501191@gargle.gargle.HOWL> (Uday S. Reddy's message of "Mon, 24 May 2010 03:04:52 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3585=0 X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 5924 Cc: 5924@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > I should take back my last couple of messages. I had a timer task > running (after 2 second delay) which was changing buffers. > Unfortunately, this was getting scheduled to run during the other > process's accept-process-output. So, I had mistakenly put the blame > on accept-process-output. Thanks for the heads up. BTW, could you try the patch below (including byte-compiling the file and re-dumping Emacs since it's a preloaded file), to see if it would have fixed your problem, even with the offending timer? Stefan PS: BTW, I recommend to stay away from set-buffer and always use with-current-buffer instead ;-) === modified file 'lisp/emacs-lisp/timer.el' --- lisp/emacs-lisp/timer.el 2010-01-13 08:35:10 +0000 +++ lisp/emacs-lisp/timer.el 2010-07-23 22:32:44 +0000 @@ -321,7 +321,11 @@ ;; We do this after rescheduling so that the handler function ;; can cancel its own timer successfully with cancel-timer. (condition-case nil - (apply (timer--function timer) (timer--args timer)) + ;; Timer functions should not change the current buffer. + ;; If they do, all kinds of nasty surprises can happen, + ;; and it can be hellish to track down their source. + (save-current-buffer + (apply (timer--function timer) (timer--args timer))) (error nil)) (if retrigger (setf (timer--triggered timer) nil))) From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 18 16:25:23 2011 Received: (at 5924) by debbugs.gnu.org; 18 Sep 2011 20:25:23 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R5NvW-0003TB-Di for submit@debbugs.gnu.org; Sun, 18 Sep 2011 16:25:23 -0400 Received: from hermes.netfonds.no ([80.91.224.195]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R5NvU-0003T5-Kg for 5924@debbugs.gnu.org; Sun, 18 Sep 2011 16:25:21 -0400 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=stories.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1R5Nqa-0005Q6-M9; Sun, 18 Sep 2011 22:20:16 +0200 From: Lars Magne Ingebrigtsen To: Stefan Monnier Subject: Re: bug#5924: 23.1; accept-process-output switching current-buffer In-Reply-To: (Stefan Monnier's message of "Sat, 24 Jul 2010 00:36:46 +0200") Date: Sun, 18 Sep 2011 22:16:41 +0200 Message-ID: References: <84mxxbknma.fsf@cs.bham.ac.uk> <19393.48894.735000.238546@gargle.gargle.HOWL> <19449.57028.88000.501191@gargle.gargle.HOWL> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) X-Now-Playing: Jane Siberry's _The Walking_ MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1R5Nqa-0005Q6-M9 X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1316982017.04131@BZBMpYI302X6GryuXcfJKw X-Spam-Status: No X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 5924 Cc: Uday S Reddy , 5924@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Stefan Monnier writes: >> I should take back my last couple of messages. I had a timer task >> running (after 2 second delay) which was changing buffers. >> Unfortunately, this was getting scheduled to run during the other >> process's accept-process-output. So, I had mistakenly put the blame >> on accept-process-output. > > Thanks for the heads up. BTW, could you try the patch below (including > byte-compiling the file and re-dumping Emacs since it's a preloaded > file), to see if it would have fixed your problem, even with the > offending timer? There was no response here last year, but the patch was apparently applied, so I'm closing this report. If this bug still persists, please reopen this report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 18 16:25:18 2011 Received: (at control) by debbugs.gnu.org; 18 Sep 2011 20:25:18 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R5NvQ-0003Sv-0u for submit@debbugs.gnu.org; Sun, 18 Sep 2011 16:25:16 -0400 Received: from hermes.netfonds.no ([80.91.224.195]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R5NvN-0003Sm-DP for control@debbugs.gnu.org; Sun, 18 Sep 2011 16:25:14 -0400 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=stories.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1R5NqU-0005Pu-02 for control@debbugs.gnu.org; Sun, 18 Sep 2011 22:20:10 +0200 Date: Sun, 18 Sep 2011 22:16:48 +0200 Message-Id: To: control@debbugs.gnu.org From: Lars Magne Ingebrigtsen Subject: control message for bug #5924 X-MailScanner-ID: 1R5NqU-0005Pu-02 X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1316982010.16051@pjho/WNO2H63riBPudrYRQ X-Spam-Status: No X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) tags 5924 fixed close 5924 24.1 From unknown Mon Jun 23 04:14:23 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 17 Oct 2011 11: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