unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Re: gnus makes emacs lose response
@ 2006-09-09 22:33 Kim F. Storm
  2006-09-10  4:10 ` Stefan Monnier
  0 siblings, 1 reply; 58+ messages in thread
From: Kim F. Storm @ 2006-09-09 22:33 UTC (permalink / raw)
  Cc: Chong Yidong, Leon


On Thu, 09/07/2006 15:48 +0100, Kim F. Storm wrote:

> From: Chong Yidong <cyd@stupidchicken.com>
> Subject: Re: gnus makes emacs lose response
> Newsgroups: gmane.emacs.devel
> Cc: emacs-devel@gnu.org, "Kim F. Storm" <no-spam@cua.dk>
> Date: Thu Sep  7 15:37:23 2006 +0100
>
>>> leon <sdl.web@googlemail.com> writes:
>>>
>>>> emacs still loses reponse and won't be able to restore to normal.
>
>>>
>>> And it doesn't respond to C-g ??
>>
>> No.
>>
>> (gdb) bt
>> #0  0x00b79248 in ___newselect_nocancel () from /lib/libc.so.6
>> #1  0x08194325 in select_wrapper (n=-514, rfd=0x0, wfd=0xbfcbe478, xfd=0x0, 
>>     tmo=0xbfcbe5a8) at process.c:4188
>> #2  0x081975e3 in wait_reading_process_output (time_limit=0, microsecs=100000, 
>>     read_kbd=0, do_display=0, wait_for_cell=137562313, wait_proc=0xac4b208, 
>>     just_wait_proc=0) at process.c:4560
>
> While Emacs is hung, could you go back to gdb, set a breakpoint at
> interrupt_signal, and see what happens when you try to run C-g?  If
> this drops you back into gdb at interrupt_signal, examine the values
> of the following variables.
>
>   b interrupt_signal
>   c
>    [Type C-g in Emacs -- this should drop back into gdb at interrupt_signal]
>   p Qnil
>   p Vquit_flag
>   p immediate_quit
>   p Vinhibit_quit
>   p waiting_for_input
>   p echoing
>
> (If C-g doesn't drop you back into gdb at interrupt_signal, then it
> probably is a kernel bug and there's nothing we can do about it).
> ----------

Here is the log. C-g can return to gdb.


GNU gdb Red Hat Linux (6.5-7.fc6rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

DISPLAY = :0.0
TERM = xterm
Breakpoint 1 at 0x80fe1d6: file emacs.c, line 464.
Breakpoint 2 at 0x8116866: file sysdep.c, line 1395.
(gdb) r
Starting program: /home/tmp/emacs/src/emacs -geometry 80x40+0+0
[Thread debugging using libthread_db enabled]
[New Thread -1208244544 (LWP 10921)]
[Switching to Thread -1208244544 (LWP 10921)]
Breakpoint 3 at 0x80d2b2c: file xterm.c, line 8039.

Program received signal SIGTSTP, Stopped (user).
0x00908402 in __kernel_vsyscall ()
(gdb) b interrupt_signal
Breakpoint 4 at 0x8102435: file keyboard.c, line 10389.
(gdb) c
Continuing.

Breakpoint 4, interrupt_signal (signalnum=0) at keyboard.c:10389
10389     int old_errno = errno;
(gdb) p Qnil
$1 = 137562313
(gdb) p Vquit_flag
$2 = 137562313
(gdb) p immediate_quit
$3 = 0
(gdb) p Vinhibit_quit
$4 = 137562361
(gdb)  p waiting_for_input
$5 = 0
(gdb)  p echoing
$6 = 0
(gdb) 


regards,
-- 
Leon

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

^ permalink raw reply	[flat|nested] 58+ messages in thread
* Re: gnus makes emacs lose response
@ 2006-09-23 18:18 Chong Yidong
  2006-09-23 23:42 ` Luc Teirlinck
  2006-09-26 17:26 ` Leo
  0 siblings, 2 replies; 58+ messages in thread
From: Chong Yidong @ 2006-09-23 18:18 UTC (permalink / raw)
  Cc: ding

After some further communication with Leon, I think I know the
problem: accept-process-output is called by the timer function
`gnus-demon' (which is a valid but IIUC not commonly-used component of
Gnus).  However, as documented in the Lisp Reference manual:

   Emacs binds `inhibit-quit' to `t' before calling the timer
   function, because quitting out of many timer functions can leave
   things in an inconsistent state.  This is normally unproblematical
   because most timer functions don't do a lot of work.  Indeed, for a
   timer to call a function that takes substantial time to run is
   likely to be annoying.

The result in this case is that this accept-process-output can't be
interrupted, and Emacs can hang if the process doesn't reply (e.g., if
the connection dies).

I'm not sure what the best way to handle this is.  Anyone?

^ permalink raw reply	[flat|nested] 58+ messages in thread
* Re: gnus makes emacs lose response
@ 2006-09-04  8:41 Kim F. Storm
  2006-09-05 21:18 ` Chong Yidong
                   ` (2 more replies)
  0 siblings, 3 replies; 58+ messages in thread
From: Kim F. Storm @ 2006-09-04  8:41 UTC (permalink / raw)
  Cc: leon


Here is an interesting backtrace from Leon:

It is hanging (C-g not working) with gnus-demon called
from a timer.  

So I suppose he is using gnus-asynchronous.

Would someone pls. investigate this.


On Sun, 03/09/06 22:19 +0100, Kim F. Storm wrote:

> leon <sdl.web@googlemail.com> writes:
>
>> I have applied the patch to the latest emacs-unicode-2 branch. I see no
>> difference.

The patch in question is this tiny patch from Stefan:

    --- orig/src/process.c
    +++ mod/src/process.c
    @@ -4255,6 +4256,9 @@
       FD_ZERO (&Connecting);
    #endif
    
    +  if (time_limit == 0 && PROCESSP (read_kbd) && !NILP (Vinhibit_quit))
    +    error ("Blocking call to accept-process-output with quit inhibited!!");
    +
       /* If wait_proc is a process to watch, set wait_channel accordingly.  */
       if (wait_proc != NULL)
         wait_channel = XINT (wait_proc->infd);
    

>> emacs still loses reponse and won't be able to restore to normal.
>
> And it doesn't respond to C-g ??

No.

>
>> I have compiled emacs with --enable-debug so if you need more debug info,
>> let me know.
>
> Can you run it under GDB and interrupt it when it is hanging and then
> look at a backtrace to see where it is hanging.

(gdb) bt
#0  0x00b79248 in ___newselect_nocancel () from /lib/libc.so.6
#1  0x08194325 in select_wrapper (n=-514, rfd=0x0, wfd=0xbfcbe478, xfd=0x0, 
    tmo=0xbfcbe5a8) at process.c:4188
#2  0x081975e3 in wait_reading_process_output (time_limit=0, microsecs=100000, 
    read_kbd=0, do_display=0, wait_for_cell=137562313, wait_proc=0xac4b208, 
    just_wait_proc=0) at process.c:4560
#3  0x08199535 in Faccept_process_output (process=180662796, seconds=0, 
    millisec=800, just_this_one=137562313) at process.c:3929
#4  0x081660a1 in Ffuncall (nargs=4, args=0xbfcbe6a0) at eval.c:2992
#5  0x0819103a in Fbyte_code (bytestr=178229091, vector=178231668, maxdepth=56)
    at bytecode.c:679
#6  0x08165aea in funcall_lambda (fun=178231796, nargs=1, 
    arg_vector=0xbfcbe7d4) at eval.c:3169
#7  0x08165ef1 in Ffuncall (nargs=2, args=0xbfcbe7d0) at eval.c:3039
#8  0x0819103a in Fbyte_code (bytestr=180188931, vector=180193340, maxdepth=40)
    at bytecode.c:679
#9  0x08165aea in funcall_lambda (fun=180193524, nargs=1, 
    arg_vector=0xbfcbe904) at eval.c:3169
#10 0x08165ef1 in Ffuncall (nargs=2, args=0xbfcbe900) at eval.c:3039
#11 0x0819103a in Fbyte_code (bytestr=180188979, vector=180193588, maxdepth=48)
    at bytecode.c:679
#12 0x08165aea in funcall_lambda (fun=180193756, nargs=0, 
    arg_vector=0xbfcbea34) at eval.c:3169
#13 0x08165ef1 in Ffuncall (nargs=1, args=0xbfcbea30) at eval.c:3039
#14 0x0819103a in Fbyte_code (bytestr=180130171, vector=180131756, maxdepth=64)
    at bytecode.c:679
#15 0x081655a5 in Feval (form=178650061) at eval.c:2319
#16 0x08164bda in internal_catch (tag=137879609, func=0x81651e0 <Feval>, 
    arg=178650061) at eval.c:1210
#17 0x08190213 in Fbyte_code (bytestr=180130155, vector=180132140, maxdepth=16)
    at bytecode.c:854
#18 0x081655a5 in Feval (form=178650021) at eval.c:2319
#19 0x08167b5f in internal_lisp_condition_case (var=137562313, 
    bodyform=178650021, handlers=178726805) at eval.c:1414
#20 0x0819032d in Fbyte_code (bytestr=180130123, vector=180132268, maxdepth=32)
    at bytecode.c:869
#21 0x081655a5 in Feval (form=178649109) at eval.c:2319
#22 0x08164bda in internal_catch (tag=180098369, func=0x81651e0 <Feval>, 
    arg=178649109) at eval.c:1210
#23 0x08190213 in Fbyte_code (bytestr=180126643, vector=180132356, maxdepth=24)
    at bytecode.c:854
#24 0x08165aea in funcall_lambda (fun=180132548, nargs=2, 
    arg_vector=0xbfcbf124) at eval.c:3169
#25 0x08165ef1 in Ffuncall (nargs=3, args=0xbfcbf120) at eval.c:3039
#26 0x0819103a in Fbyte_code (bytestr=171316339, vector=177631276, maxdepth=56)
    at bytecode.c:679
#27 0x08165aea in funcall_lambda (fun=142210388, nargs=2, 
    arg_vector=0xbfcbf254) at eval.c:3169
#28 0x08165ef1 in Ffuncall (nargs=3, args=0xbfcbf250) at eval.c:3039
#29 0x0819103a in Fbyte_code (bytestr=140306195, vector=139585188, maxdepth=48)
    at bytecode.c:679
#30 0x08165aea in funcall_lambda (fun=139585356, nargs=2, 
    arg_vector=0xbfcbf384) at eval.c:3169
#31 0x08165ef1 in Ffuncall (nargs=3, args=0xbfcbf380) at eval.c:3039
#32 0x0819103a in Fbyte_code (bytestr=141543491, vector=139584628, maxdepth=72)
    at bytecode.c:679
#33 0x08165aea in funcall_lambda (fun=139585124, nargs=2, 
    arg_vector=0xbfcbf460) at eval.c:3169
#34 0x08165ce6 in apply_lambda (fun=139585124, args=171439901, eval_flag=1)
    at eval.c:3093
#35 0x081653c2 in Feval (form=170540757) at eval.c:2355
#36 0x08167b5f in internal_lisp_condition_case (var=137562313, 
    bodyform=170540757, handlers=170540085) at eval.c:1414
#37 0x0819032d in Fbyte_code (bytestr=141543811, vector=177674908, maxdepth=40)
    at bytecode.c:869
#38 0x08165aea in funcall_lambda (fun=177675100, nargs=0, 
    arg_vector=0xbfcbf764) at eval.c:3169
#39 0x08165ef1 in Ffuncall (nargs=1, args=0xbfcbf760) at eval.c:3039
#40 0x0819103a in Fbyte_code (bytestr=140992715, vector=140994924, maxdepth=24)
    at bytecode.c:679
#41 0x08165aea in funcall_lambda (fun=142487924, nargs=0, 
    arg_vector=0xbfcbf884) at eval.c:3169
#42 0x08165ef1 in Ffuncall (nargs=1, args=0xbfcbf880) at eval.c:3039
#43 0x0819103a in Fbyte_code (bytestr=181723363, vector=182785316, maxdepth=8)
    at bytecode.c:679
#44 0x081655a5 in Feval (form=181649869) at eval.c:2319
#45 0x08167b5f in internal_lisp_condition_case (var=137562313, 
    bodyform=181649869, handlers=181649645) at eval.c:1414
#46 0x0819032d in Fbyte_code (bytestr=181723379, vector=146709364, maxdepth=64)
    at bytecode.c:869
#47 0x08165aea in funcall_lambda (fun=146709548, nargs=0, 
    arg_vector=0xbfcbfc48) at eval.c:3169
#48 0x08165ef1 in Ffuncall (nargs=1, args=0xbfcbfc44) at eval.c:3039
#49 0x08167768 in Fapply (nargs=2, args=0xbfcbfc44) at eval.c:2411
#50 0x08166215 in Ffuncall (nargs=3, args=0xbfcbfc40) at eval.c:2963
#51 0x0819103a in Fbyte_code (bytestr=136629355, vector=136629380, maxdepth=32)
    at bytecode.c:679
#52 0x081655a5 in Feval (form=136629341) at eval.c:2319
#53 0x08167b5f in internal_lisp_condition_case (var=137562313, 
    bodyform=136629341, handlers=136629413) at eval.c:1414
#54 0x0819032d in Fbyte_code (bytestr=136629211, vector=136629228, maxdepth=40)
    at bytecode.c:869
#55 0x08165aea in funcall_lambda (fun=136629172, nargs=1, 
    arg_vector=0xbfcbff74) at eval.c:3169
#56 0x08165ef1 in Ffuncall (nargs=2, args=0xbfcbff70) at eval.c:3039
#57 0x08167359 in call1 (fn=137591681, arg1=146720244) at eval.c:2767
#58 0x08106aa6 in timer_check (do_it_now=1) at keyboard.c:4519
#59 0x08106cb9 in readable_events (flags=1) at keyboard.c:3544
#60 0x08106d27 in get_input_pending (addr=0x831e320, flags=1)
    at keyboard.c:6638
#61 0x08106e00 in detect_input_pending_run_timers (do_display=1)
    at keyboard.c:10014
#62 0x081971a6 in wait_reading_process_output (time_limit=0, microsecs=0, 
    read_kbd=-1, do_display=1, wait_for_cell=137562313, wait_proc=0x0, 
    just_wait_proc=0) at process.c:4663
#63 0x0810a1f5 in read_char (commandflag=1, nmaps=7, maps=0xbfcc05d0, 
    prev_event=137562313, used_mouse_menu=0xbfcc0688, end_time=0x0)
    at keyboard.c:3980
#64 0x0810c726 in read_key_sequence (keybuf=0xbfcc0734, bufsize=30, 
    prompt=137562313, dont_downcase_last=0, can_return_switch_frame=1, 
    fix_current_buffer=1) at keyboard.c:8917
#65 0x0810e1e3 in command_loop_1 () at keyboard.c:1538
#66 0x08164b22 in internal_condition_case (bfun=0x810e050 <command_loop_1>, 
    handlers=137600937, hfun=0x8108c90 <cmd_error>) at eval.c:1469
#67 0x081080b3 in command_loop_2 () at keyboard.c:1329
#68 0x08164bda in internal_catch (tag=137594921, 
    func=0x8108090 <command_loop_2>, arg=137562313) at eval.c:1210
#69 0x08108acc in command_loop () at keyboard.c:1308
#70 0x08108e6a in recursive_edit_1 () at keyboard.c:1006
#71 0x08108f57 in Frecursive_edit () at keyboard.c:1067
#72 0x080fefe2 in main (argc=3, argv=0xbfcc0e34) at emacs.c:1814

Lisp Backtrace:
"accept-process-output" (0xac4b20c)
"nnheader-accept-process-output" (0xac4b20c)
"nntp-accept-process-output" (0xac4b20c)
"nntp-accept-response" (0x350)
"byte-code" (0xabc917b)
"byte-code" (0xabc916b)
"byte-code" (0xabc914b)
"nntp-retrieve-groups" (0xad3bc7d)
"gnus-retrieve-groups" (0xad3bc7d)
"gnus-read-active-file-2" (0xad3bc7d)
"gnus-read-active-file-1" (0xa69d4fd)
"gnus-read-active-file" (0x83308c9)
"gnus-group-get-new-news" (0x2a)
"byte-code" (0xad4e0e3)
"gnus-demon" (0x83308c9)
"apply" (0xabbfc71)
"byte-code" (0x824cc6b)
"timer-event-handler" (0x8bec5f4)
(gdb)

(gdb) bt full
#0  0x00b79248 in ___newselect_nocancel () from /lib/libc.so.6
No symbol table info available.
#1  0x08194325 in select_wrapper (n=-514, rfd=0x0, wfd=0xbfcbe478, xfd=0x0, 
    tmo=0xbfcbe5a8) at process.c:4188
No locals.
#2  0x081975e3 in wait_reading_process_output (time_limit=0, microsecs=100000, 
    read_kbd=0, do_display=0, wait_for_cell=137562313, wait_proc=0xac4b208, 
    just_wait_proc=0) at process.c:4560
        usecs = <value optimized out>
        timeout_reduced_for_timers = 0
        channel = 0
        nfds = 0
        Available = {
  fds_bits = {389248, 0 <repeats 31 times>}
}
        Connecting = {
  fds_bits = {0 <repeats 32 times>}
}
        check_connect = 0
        check_delay = 0
        no_avail = 0
        xerrno = 0
        proc = <value optimized out>
        timeout = {
  tv_sec = 0, 
  tv_usec = 40000
}
        end_time = {
  tv_sec = 1157323517, 
  tv_usec = 457274
}
        wait_channel = 12
        got_some_input = 0
#3  0x08199535 in Faccept_process_output (process=180662796, seconds=0, 
    millisec=800, just_this_one=137562313) at process.c:3929
        carry = <value optimized out>
        secs = 0
        usecs = 100000
#4  0x081660a1 in Ffuncall (nargs=4, args=0xbfcbe6a0) at eval.c:2992
        fun = <value optimized out>
        original_fun = 4
        funcar = <value optimized out>
        numargs = 3
        val = <value optimized out>
        backtrace = {
  next = 0xbfcbe798, 
  function = 0xbfcbe6a0, 
  args = 0xbfcbe6a4, 
  nargs = 3, 
  evalargs = 0 '\0', 
  debug_on_exit = 0 '\0'
}
        internal_args = (Lisp_Object *) 0xbfcbe630
        i = <value optimized out>
#5  0x0819103a in Fbyte_code (bytestr=178229091, vector=178231668, maxdepth=56)
    at bytecode.c:679
        v1 = <value optimized out>
        v2 = <value optimized out>
        op = dwarf2_read_address: Corrupted DWARF expression.

Lisp Backtrace:
"accept-process-output" (0xac4b20c)
"nnheader-accept-process-output" (0xac4b20c)
"nntp-accept-process-output" (0xac4b20c)
"nntp-accept-response" (0x350)
"byte-code" (0xabc917b)
"byte-code" (0xabc916b)
"byte-code" (0xabc914b)
"nntp-retrieve-groups" (0xad3bc7d)
"gnus-retrieve-groups" (0xad3bc7d)
"gnus-read-active-file-2" (0xad3bc7d)
"gnus-read-active-file-1" (0xa69d4fd)
"gnus-read-active-file" (0x83308c9)
"gnus-group-get-new-news" (0x2a)
"byte-code" (0xad4e0e3)
"gnus-demon" (0x83308c9)
"apply" (0xabbfc71)
"byte-code" (0x824cc6b)
"timer-event-handler" (0x8bec5f4)
(gdb)

^ permalink raw reply	[flat|nested] 58+ messages in thread
[parent not found: <m2lkuuynpf.fsf@sl392.st-edmunds.cam.ac.uk>]
end of thread, other threads:[~2006-09-26 19:20 UTC | newest]

Thread overview: 58+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-09 22:33 gnus makes emacs lose response 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
  -- strict thread matches above, loose matches on Subject: below --
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
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
     [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   ` 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
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

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).