From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: emacs gets stuck in wait_reading_process_output sometimes Date: Wed, 11 Jun 2008 21:47:26 +0200 Message-ID: <857icvvjn5.fsf@lola.goethe.zz> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1213213696 21670 80.91.229.12 (11 Jun 2008 19:48:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Jun 2008 19:48:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: joakim@verona.se Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 11 21:48:58 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1K6WJ2-0005aE-9Q for ged-emacs-devel@m.gmane.org; Wed, 11 Jun 2008 21:48:28 +0200 Original-Received: from localhost ([127.0.0.1]:46920 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K6WIE-0004bj-Py for ged-emacs-devel@m.gmane.org; Wed, 11 Jun 2008 15:47:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K6WI7-0004WW-Ek for emacs-devel@gnu.org; Wed, 11 Jun 2008 15:47:31 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K6WI6-0004Th-CX for emacs-devel@gnu.org; Wed, 11 Jun 2008 15:47:30 -0400 Original-Received: from [199.232.76.173] (port=46070 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K6WI5-0004TU-QR for emacs-devel@gnu.org; Wed, 11 Jun 2008 15:47:29 -0400 Original-Received: from mail-in-03.arcor-online.net ([151.189.21.43]:54923) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K6WI5-0003fN-MM for emacs-devel@gnu.org; Wed, 11 Jun 2008 15:47:29 -0400 Original-Received: from mail-in-09-z2.arcor-online.net (mail-in-09-z2.arcor-online.net [151.189.8.21]) by mail-in-03.arcor-online.net (Postfix) with ESMTP id A258C2CB02A; Wed, 11 Jun 2008 21:47:27 +0200 (CEST) Original-Received: from mail-in-14.arcor-online.net (mail-in-14.arcor-online.net [151.189.21.54]) by mail-in-09-z2.arcor-online.net (Postfix) with ESMTP id 9AD9828EDE8; Wed, 11 Jun 2008 21:47:27 +0200 (CEST) Original-Received: from lola.goethe.zz (dslb-084-061-006-252.pools.arcor-ip.net [84.61.6.252]) by mail-in-14.arcor-online.net (Postfix) with ESMTP id 32AE2187BC8; Wed, 11 Jun 2008 21:47:27 +0200 (CEST) Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id AFF7E1C4F92A; Wed, 11 Jun 2008 21:47:26 +0200 (CEST) In-Reply-To: (joakim@verona.se's message of "Wed, 11 Jun 2008 21:09:34 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-Virus-Scanned: ClamAV 0.93/7407/Mon Jun 9 04:21:00 2008 on mail-in-14.arcor-online.net X-Virus-Status: Clean X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:98975 Archived-At: joakim@verona.se writes: > #0 0x00110422 in __kernel_vsyscall () > #1 0x00cb85bd in ___newselect_nocancel () from /lib/libc.so.6 > #2 0x081adc25 in select_wrapper (n=-514, rfd=0x0, wfd=0xbfd5a178, xfd=0x0, tmo=0xbfd5a2a8) at process.c:4204 > #3 0x081b0e3f in wait_reading_process_output (time_limit=0, microsecs=10000, read_kbd=0, do_display=0, wait_for_cell=137764129, wait_proc=0xb819ca0, just_wait_proc=0) at process.c:4587 > #4 0x081b2de7 in Faccept_process_output (process=193043620, seconds=0, millisec=80, just_this_one=137764129) at process.c:3946 > > This only happens sometimes. > > I have a small elisp wrapper for fetchmail, and I think the stuckness > might happen when fetchmail exits, but I'm not sure. > > Any hints how to debug this better when it happens? Can you check whether it is related to the setting of process-adaptive-read-buffering? I seem to remember that tramp explicitly disabled it to get rid of large inexplicable delays, so it is not unlikely that there is still some bug lurking in there. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum