emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnus makes emacs lose response


From: Kim F. Storm
Subject: Re: gnus makes emacs lose response
Date: Mon, 24 Apr 2006 02:41:32 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Gregory Novak <address@hidden> writes:

> Ralf Angeli <address@hidden> 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 <address@hidden> http://www.cua.dk





reply via email to

[Prev in Thread] Current Thread [Next in Thread]