|
From: | Chong Yidong |
Subject: | [Leon] Re: gnus makes emacs lose response |
Date: | Wed, 20 Sep 2006 23:22:01 -0400 |
User-agent: | Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
--- Begin Message ---Subject: Re: gnus makes emacs lose response Date: Thu, 21 Sep 2006 04:05:00 +0100 User-agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.0 (gnu/linux) On Wed, 09/20/2006 22:26 +0100, Chong Yidong wrote: > Leon <address@hidden> writes: > >> Chong, >> >> On Sat, 09/16/2006 21:22 +0100, Chong Yidong wrote: >> >>> Stefan Monnier <address@hidden> writes: >>> >>>>> (gdb) p Qnil >>>>> $1 = 137562313 >>>>> (gdb) p Vquit_flag >>>>> $2 = 137562313 >>>>> (gdb) p immediate_quit >>>>> $3 = 0 >>>>> (gdb) p Vinhibit_quit >>>>> $4 = 137562361 >>>> >>>> So inhibit-quit is non-nil, so shouldn't my patch have caught this? >>>> What does the xbacktrace look like? >>> >>> Could we get this discussion moving again? >> >> I am happy to. But I don't know what to do with it. I know no C >> program, let alone debug. If you can list the steps, I probably can do >> it! > > Could you apply this patch to process.c, recompile, and see if you can > still get Emacs stuck? It should signal an error, in which case > please send the Lisp backtrace (turn debug-on-error to t). > > *** emacs/src/process.c.~1.488.~ 2006-09-08 16:32:57.000000000 -0400 > --- emacs/src/process.c 2006-09-20 17:24:21.000000000 -0400 > *************** > *** 4254,4259 **** > --- 4254,4262 ---- > int got_some_input = 0; > int count = SPECPDL_INDEX (); > > + if (time_limit == 0 && wait_proc && !NILP (Vinhibit_quit)) > + error ("Blocking call to accept-process-output with quit inhibited!!"); > + > FD_ZERO (&Available); > #ifdef NON_BLOCKING_CONNECT > FD_ZERO (&Connecting); > ---- Emacs: GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.10.3) of 2006-09-19 on Hawk OS: Fedora Core 6 ---- This patch seems to partially fix the problem. I fire up gnus with (gnus-demon-add-handler 'gnus-group-get-new-news 1 t) (gnus-demon-init) The first time gnus hangs, C-g restores it to normal correctly. And then I wait a while until the second time gnus hangs, C-g correctly restores it to normal too. However, the third time gnus hangs the symptom is similar to the case without the patch: C-g won't be able to stop the process. I have turned on debug-on-error, but I didn't get any backtrace. So I go back to gdb and take the log of running bt, xba and bt full etc. The logs are attached.bt.log
Description: bt.logxba.log
Description: xba.logbt_full.log
Description: bt_full.logmisc.log
Description: misc.log-- Leon
--- End Message ---
[Prev in Thread] | Current Thread | [Next in Thread] |