unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: storm@cua.dk (Kim F. Storm)
Cc: emacs-devel@gnu.org
Subject: Re: gnus makes emacs lose response
Date: Mon, 24 Apr 2006 02:41:32 +0200	[thread overview]
Message-ID: <m3veszoldv.fsf@kfs-l.imdomain.dk> (raw)
In-Reply-To: <m2ejzscecg.fsf@euterpe.local> (Gregory Novak's message of "Thu, 20 Apr 2006 11:05:19 -0700")

Gregory Novak <novak@ucolick.org> writes:

> Ralf Angeli <angeli@iwi.uni-sb.de> 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 <Feval>,
    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 <return> to continue, or q <return> 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 <command_loop_1>,
---Type <return> to continue, or q <return> to quit---
    handlers=137926161, hfun=0x8112948 <cmd_error>) at eval.c:1474
#55 0x08112c7b in command_loop_2 () at keyboard.c:1328
#56 0x0818b7fe in internal_catch (tag=137922393,
    func=0x8112c5c <command_loop_2>, 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 <storm@cua.dk> http://www.cua.dk

  reply	other threads:[~2006-04-24  0:41 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <m2lkuuynpf.fsf@sl392.st-edmunds.cam.ac.uk>
     [not found] ` <m24q18rize.fsf@sl392.st-edmunds.cam.ac.uk>
2006-04-05  8:47   ` gnus makes emacs lose response Kim F. Storm
2006-04-05 17:55     ` Leon
2006-04-06  9:08       ` Kim F. Storm
2006-04-06 21:15         ` Leon
2006-04-07  8:13           ` Kim F. Storm
2006-04-07 13:25             ` Leon
2006-04-07 20:58         ` Ralf Angeli
2006-04-09  1:17           ` Leon
2006-04-17 20:35           ` Ralf Angeli
2006-04-18  1:46             ` Leon
2006-04-19 20:18               ` Ralf Angeli
2006-04-20  1:19                 ` Leon
2006-04-19 20:18             ` Ralf Angeli
2006-04-19 20:51               ` Stefan Monnier
2006-04-19 21:13                 ` Ralf Angeli
2006-04-20 18:05               ` Gregory Novak
2006-04-24  0:41                 ` Kim F. Storm [this message]
2006-08-22 11:44               ` Kim F. Storm
2006-08-23 14:45                 ` Richard Stallman
2006-08-23 15:00                   ` Kim F. Storm
2006-08-25  7:43                     ` Richard Stallman
2006-08-25  8:15                       ` Kim F. Storm
2006-08-26 10:08                         ` Richard Stallman
2006-08-26 21:32                           ` Kim F. Storm
2006-08-25  8:56                       ` Jason Rumney
2006-08-23 20:51                   ` Stefan Monnier
2006-08-24  3:17                   ` Bob Rogers
2006-08-24  7:51                     ` Kim F. Storm
2006-08-25  1:01                       ` Bob Rogers
2006-08-25 20:23                       ` Richard Stallman
2006-08-25  7:44                     ` Richard Stallman
2006-09-04  8:41 Kim F. Storm
2006-09-05 21:18 ` Chong Yidong
2006-09-05 21:21   ` Stefan Monnier
2006-09-07 20:43     ` Chong Yidong
2006-09-08 11:56       ` Richard Stallman
2006-09-06 19:06   ` Richard Stallman
2006-09-07 14:37 ` Chong Yidong
2006-09-22 20:04 ` Chong Yidong
2006-09-25  0:39   ` Stefan Monnier
2006-09-25 15:22     ` Chong Yidong
  -- strict thread matches above, loose matches on Subject: below --
2006-09-09 22:33 Kim F. Storm
2006-09-10  4:10 ` Stefan Monnier
2006-09-16 20:22   ` Chong Yidong
2006-09-18 14:40   ` Chong Yidong
2006-09-18 14:53     ` Chong Yidong
2006-09-19 10:45       ` Stefan Monnier
2006-09-19 15:02         ` Chong Yidong
2006-09-22 19:12           ` Stefan Monnier
2006-09-23 18:01             ` Richard Stallman
2006-09-23  3:34         ` Richard Stallman
2006-09-23 15:02           ` Stefan Monnier
2006-09-18 14:55     ` Stefan Monnier
2006-09-23 18:18 Chong Yidong
2006-09-23 23:42 ` Luc Teirlinck
2006-09-26 17:26 ` Leo
2006-09-26 18:08   ` Chong Yidong
2006-09-26 19:20     ` Leo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3veszoldv.fsf@kfs-l.imdomain.dk \
    --to=storm@cua.dk \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).