From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: gnus makes emacs lose response Date: Mon, 24 Apr 2006 02:41:32 +0200 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1145839438 21842 80.91.229.2 (24 Apr 2006 00:43:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 24 Apr 2006 00:43:58 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 24 02:43:54 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FXpBA-0007Zq-Ta for ged-emacs-devel@m.gmane.org; Mon, 24 Apr 2006 02:43:53 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FXpBA-00013X-S3 for ged-emacs-devel@m.gmane.org; Sun, 23 Apr 2006 20:43:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FXpB0-00013S-6z for emacs-devel@gnu.org; Sun, 23 Apr 2006 20:43:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FXpAy-00013G-RK for emacs-devel@gnu.org; Sun, 23 Apr 2006 20:43:41 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FXpAy-00013D-KK for emacs-devel@gnu.org; Sun, 23 Apr 2006 20:43:40 -0400 Original-Received: from [195.41.46.237] (helo=pfepc.post.tele.dk) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FXpD5-0000tZ-DX for emacs-devel@gnu.org; Sun, 23 Apr 2006 20:45:51 -0400 Original-Received: from kfs-l.imdomain.dk.cua.dk (0x503e2644.bynxx3.adsl-dhcp.tele.dk [80.62.38.68]) by pfepc.post.tele.dk (Postfix) with SMTP id 18F37262801; Mon, 24 Apr 2006 02:43:37 +0200 (CEST) Original-To: Gregory Novak In-Reply-To: (Gregory Novak's message of "Thu, 20 Apr 2006 11:05:19 -0700") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:53297 Archived-At: Gregory Novak writes: > Ralf Angeli writes: >> After some messing around I found the difference between between both >> cases. Under Windows the process (e.g. openssl s_client) dies as soon >> as the modem connection is closed while on GNU/Linux it is kept alive. >> That means after reconnecting to the internet under Windows a new >> process is started which has no problem communicating to the server >> while on GNU/Linux the old one is reused which obviously cannot cope >> with the new internet connection. > > I just wanted to add a bit of my own experience to this. I use Gnus > to read mail under Emacs 21.4 and My IMAP server seems to be fond of > closing the connection after a relatively short period of inactivity. > This leads to the behavior noted -- Gnus seems to hang but C-g works. > I usually deal with this by quitting and restarting Gnus one or two > times, or else searching for the gnutls process and killing it from > the command line. Perhaps there could be a short timeout (like 10 > seconds) after which Emacs asks "The connection looks like it might be > dead--kill it and start a new one? (y/n)" > > Most of my Emacs work is done using a recent CVS build of the Carbon > port. I used to read mail with Gnus using this copy of Emacs, but I > _have_ experienced hangs that are unbreakable with C-g. This was > sufficiently annoying that I just run the 21.4 version of Emacs for > mail and nothing else. Under 21.4, I've never experienced an > unbreakable hang in Gnus. > > All of this is on OS X 10.4 using the Fink build of Emacs 21.4 and > some (more or less randomly updated) Carbon build of Emacs from CVS. I just got into a similar Gnus "hang", but didn't see anything really odd about it -- and C-g eventually got me going again. Could just be the news server which had a hick-up. Program received signal SIGTSTP, Stopped (user). 0xffffe002 in ?? () (gdb) bt #0 0xffffe002 in ?? () #1 0x081c9d37 in Faccept_process_output (process=156753284, seconds=0, millisec=800, just_this_one=137881521) at process.c:3899 #2 0x0818df5f in Ffuncall (nargs=4, args=0xbfffbef0) at eval.c:2912 #3 0x081c212d in Fbyte_code (bytestr=144407107, vector=144409220, maxdepth=56) at bytecode.c:694 #4 0x0818e654 in funcall_lambda (fun=144409348, nargs=1, arg_vector=0xbfffc0d4) at eval.c:3089 #5 0x0818e09c in Ffuncall (nargs=2, args=0xbfffc0d0) at eval.c:2948 #6 0x081c212d in Fbyte_code (bytestr=145793651, vector=145788340, maxdepth=40) at bytecode.c:694 #7 0x0818e654 in funcall_lambda (fun=145750972, nargs=1, arg_vector=0xbfffc2b4) at eval.c:3089 #8 0x0818e09c in Ffuncall (nargs=2, args=0xbfffc2b0) at eval.c:2948 #9 0x081c212d in Fbyte_code (bytestr=144475355, vector=144617460, maxdepth=48) at bytecode.c:694 #10 0x0818d1f7 in Feval (form=145259293) at eval.c:2248 #11 0x0818bc59 in internal_lisp_condition_case (var=138208761, bodyform=145259293, handlers=145254109) at eval.c:1419 #12 0x081c2ab1 in Fbyte_code (bytestr=144475323, vector=145430532, maxdepth=64) at bytecode.c:884 #13 0x0818e654 in funcall_lambda (fun=146115068, nargs=3, arg_vector=0xbfffc7d4) at eval.c:3089 #14 0x0818e09c in Ffuncall (nargs=4, args=0xbfffc7d0) at eval.c:2948 #15 0x081c212d in Fbyte_code (bytestr=146197051, vector=145492420, maxdepth=40) at bytecode.c:694 #16 0x0818d1f7 in Feval (form=145206317) at eval.c:2248 #17 0x0818bc59 in internal_lisp_condition_case (var=137881521, bodyform=145206317, handlers=145206245) at eval.c:1419 #18 0x081c2ab1 in Fbyte_code (bytestr=146197019, vector=145509540, maxdepth=32) at bytecode.c:884 #19 0x0818d1f7 in Feval (form=145208061) at eval.c:2248 #20 0x0818b7fe in internal_catch (tag=144451065, func=0x818cd4b , arg=145208061) at eval.c:1212 #21 0x081c2a46 in Fbyte_code (bytestr=146196827, vector=144411020, maxdepth=24) at bytecode.c:869 #22 0x0818e654 in funcall_lambda (fun=145512148, nargs=4, arg_vector=0xbfffcfd4) at eval.c:3089 #23 0x0818e09c in Ffuncall (nargs=5, args=0xbfffcfd0) at eval.c:2948 #24 0x081c212d in Fbyte_code (bytestr=145991619, vector=145994684, maxdepth=40) at bytecode.c:694 #25 0x0818e654 in funcall_lambda (fun=145994844, nargs=3, arg_vector=0xbfffd1b4) at eval.c:3089 #26 0x0818e09c in Ffuncall (nargs=4, args=0xbfffd1b0) at eval.c:2948 #27 0x081c212d in Fbyte_code (bytestr=146629483, vector=146597396, maxdepth=48) ---Type to continue, or q to quit--- at bytecode.c:694 #28 0x0818e654 in funcall_lambda (fun=146597804, nargs=2, arg_vector=0xbfffd394) at eval.c:3089 #29 0x0818e09c in Ffuncall (nargs=3, args=0xbfffd390) at eval.c:2948 #30 0x081c212d in Fbyte_code (bytestr=146717859, vector=146718684, maxdepth=32) at bytecode.c:694 #31 0x0818e654 in funcall_lambda (fun=146719068, nargs=2, arg_vector=0xbfffd564) at eval.c:3089 #32 0x0818e09c in Ffuncall (nargs=3, args=0xbfffd560) at eval.c:2948 #33 0x081c212d in Fbyte_code (bytestr=146417523, vector=146421668, maxdepth=32) at bytecode.c:694 #34 0x0818e654 in funcall_lambda (fun=146421876, nargs=2, arg_vector=0xbfffd734) at eval.c:3089 #35 0x0818e09c in Ffuncall (nargs=3, args=0xbfffd730) at eval.c:2948 #36 0x081c212d in Fbyte_code (bytestr=146435787, vector=146439884, maxdepth=32) at bytecode.c:694 #37 0x0818e654 in funcall_lambda (fun=146440060, nargs=1, arg_vector=0xbfffd904) at eval.c:3089 #38 0x0818e09c in Ffuncall (nargs=2, args=0xbfffd900) at eval.c:2948 #39 0x081c212d in Fbyte_code (bytestr=145604011, vector=145614828, maxdepth=56) at bytecode.c:694 #40 0x0818e654 in funcall_lambda (fun=145615356, nargs=6, arg_vector=0xbfffdae4) at eval.c:3089 #41 0x0818e09c in Ffuncall (nargs=7, args=0xbfffdae0) at eval.c:2948 #42 0x081c212d in Fbyte_code (bytestr=145603979, vector=145614372, maxdepth=64) at bytecode.c:694 #43 0x0818e654 in funcall_lambda (fun=145614548, nargs=7, arg_vector=0xbfffdcc4) at eval.c:3089 #44 0x0818e09c in Ffuncall (nargs=8, args=0xbfffdcc0) at eval.c:2948 #45 0x081c212d in Fbyte_code (bytestr=145700403, vector=145675132, maxdepth=64) at bytecode.c:694 #46 0x0818e654 in funcall_lambda (fun=145675348, nargs=3, arg_vector=0xbfffdea4) at eval.c:3089 #47 0x0818e09c in Ffuncall (nargs=4, args=0xbfffdea0) at eval.c:2948 #48 0x081c212d in Fbyte_code (bytestr=149159459, vector=149061108, maxdepth=32) at bytecode.c:694 #49 0x0818e654 in funcall_lambda (fun=149061260, nargs=1, arg_vector=0xbfffe0a4) at eval.c:3089 #50 0x0818e09c in Ffuncall (nargs=2, args=0xbfffe0a0) at eval.c:2948 #51 0x08189b50 in Fcall_interactively (function=146253745, record_flag=137881521, keys=137922020) at callint.c:884 #52 0x08120ac3 in Fcommand_execute (cmd=146253745, record_flag=137881521, keys=137881521, special=137881521) at keyboard.c:9760 #53 0x081141d6 in command_loop_1 () at keyboard.c:1791 #54 0x0818bd8d in internal_condition_case (bfun=0x8112e03 , ---Type to continue, or q to quit--- handlers=137926161, hfun=0x8112948 ) at eval.c:1474 #55 0x08112c7b in command_loop_2 () at keyboard.c:1328 #56 0x0818b7fe in internal_catch (tag=137922393, func=0x8112c5c , arg=137881521) at eval.c:1212 #57 0x08112c2e in command_loop () at keyboard.c:1307 #58 0x081126c7 in recursive_edit_1 () at keyboard.c:1000 #59 0x08112808 in Frecursive_edit () at keyboard.c:1061 #60 0x08111111 in main (argc=3, argv=0xbfffe9a4) at emacs.c:1789 #61 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6 Lisp Backtrace: "accept-process-output" (0x957dd84) "nnheader-accept-process-output" (0x957dd84) "nntp-accept-process-output" (0x957dd84) "byte-code" (0x89c84db) "nntp-send-command-and-decode" (0x8b6ca4b) "byte-code" (0x8b6ca3b) "byte-code" (0x8b6ca1b) "nntp-request-article" (0x46bc8) "gnus-request-article" (0x46bc8) "gnus-request-article-this-buffer" (0x46bc8) "gnus-article-prepare" (0x46bc8) "gnus-summary-display-article" (0x46bc8) "gnus-summary-goto-article" (0x46bc8) "gnus-summary-read-group-1" (0x8d4fe53) "gnus-summary-read-group" (0x8d4fe53) "gnus-group-read-group" (0x837e7b1) "gnus-topic-read-group" (0x837e7b1) "call-interactively" (0x8b7a7b1) (gdb) up #1 0x081c9d37 in Faccept_process_output (process=156753284, seconds=0, millisec=800, just_this_one=137881521) at process.c:3899 3899 return (gdb) do #0 0xffffe002 in ?? () (gdb) up #1 0x081c9d37 in Faccept_process_output (process=156753284, seconds=0, millisec=800, just_this_one=137881521) at process.c:3899 3899 return (gdb) list 3894 secs = -1, usecs = 0; 3895 } 3896 else 3897 secs = NILP (process) ? -1 : 0; 3898 3899 return 3900 (wait_reading_process_output (secs, usecs, 0, 0, 3901 Qnil, 3902 !NILP (process) ? XPROCESS (process) : NULL, 3903 NILP (just_this_one) ? 0 : (gdb) pp just_this_one nil -- Kim F. Storm http://www.cua.dk