Re: gnus makes emacs lose response

Re: gnus makes emacs lose response

[Kim F. Storm]

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)

Re: gnus makes emacs lose response

[Chong Yidong]

no-spam@cua.dk (Kim F. Storm) writes:

> Here is an interesting backtrace from Leon:
>
> It is hanging (C-g not working) with gnus-demon called
> from a timer.  
>
> Would someone pls. investigate this.

If I remember correctly from previous discussions, this bug happens
when a cable is unplugged while Gnus is running, and it's been around
for years.

>From the backtrace, it looks Emacs is hanging on the select call.  My
guess is that the unplugged network cable causes select to wait
forever, in spite of the non-NULL timeout argument passed to it.  If
this is true, it's a bug in the select system call, and there's little
Emacs can do to work around it.

> (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


> #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

Re: gnus makes emacs lose response

[Stefan Monnier]

>> Here is an interesting backtrace from Leon:
>> 
>> It is hanging (C-g not working) with gnus-demon called
>> from a timer.  
>> 
>> Would someone pls. investigate this.

> If I remember correctly from previous discussions, this bug happens
> when a cable is unplugged while Gnus is running, and it's been around
> for years.

>> From the backtrace, it looks Emacs is hanging on the select call.  My
> guess is that the unplugged network cable causes select to wait
> forever, in spite of the non-NULL timeout argument passed to it.  If
> this is true, it's a bug in the select system call, and there's little
> Emacs can do to work around it.

That's the for the "hang" part.  But there's another problem which is the
"C-g not working" part, for which Emacs should be able to do something.


        Stefan

Re: gnus makes emacs lose response

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> From the backtrace, it looks Emacs is hanging on the select call.
>> My guess is that the unplugged network cable causes select to wait
>> forever, in spite of the non-NULL timeout argument passed to it.
>> If this is true, it's a bug in the select system call, and there's
>> little Emacs can do to work around it.
>
> That's the for the "hang" part.  But there's another problem which
> is the "C-g not working" part, for which Emacs should be able to do
> something.

Unless the hang in the select system call prevents C-g from calling
interrupt_signal in the first place, which we couldn't possibly do
anything about.

Re: gnus makes emacs lose response

[Richard Stallman]

    Unless the hang in the select system call prevents C-g from calling
    interrupt_signal in the first place, which we couldn't possibly do
    anything about.

If that is true, it is a serious kernel bug.  Can anyone verify that
that is true?

Re: gnus makes emacs lose response

[Richard Stallman]

    >From the backtrace, it looks Emacs is hanging on the select call.  My
    guess is that the unplugged network cable causes select to wait
    forever, in spite of the non-NULL timeout argument passed to it.  If
    this is true, it's a bug in the select system call, and there's little
    Emacs can do to work around it.

Can you verify that the select call is really doing this?
If it is really a kernel bug, let's get it reported, so it will get fixed.

Re: gnus makes emacs lose response

[Chong Yidong]

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

Re: gnus makes emacs lose response

[Chong Yidong]

After some communication with Leon, I found out that `gnus-demon' was
being called with inhibit-quit set to t.  This is done by timer_check
in keyboard.c:4528.

      /* Mark the timer as triggered to prevent problems if the lisp
	 code fails to reschedule it right.  */
      vector[0] = Qt;

      specbind (Qinhibit_quit, Qt);

      call1 (Qtimer_event_handler, chosen_timer);

This behavior is 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.

However, the result is that when the `gnus-demon' timer function calls
accept-process-output, it can't be interrupted.

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

Re: gnus makes emacs lose response

[Stefan Monnier]

> This behavior is 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.

> However, the result is that when the `gnus-demon' timer function calls
> accept-process-output, it can't be interrupted.

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

`with-local-quit'.
The manual should be changed to point to it,


        Stefan

Re: gnus makes emacs lose response

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> This behavior is 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.
>
>> However, the result is that when the `gnus-demon' timer function calls
>> accept-process-output, it can't be interrupted.
>
>> I'm not sure what the best way to handle this is.  Anyone?
>
> `with-local-quit'.
> The manual should be changed to point to it,

I've checked in a fix, which Leon has confirmed to fix his problem.
(I've updated the lispref manual too.)

Re: gnus makes emacs lose response

[Chong Yidong]

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?

Re: gnus makes emacs lose response

[Luc Teirlinck]

Chong Yidong wrote:

   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?

I have no time to look at the actual code, but is there any reason why
the routine way to handle this problem, namely using `with-local-quit'
(see (elisp)Quitting) around the problematic code (in this case
probably the call to accept-process-output) does not work in this case?

Sincerely,

Luc.

Re: gnus makes emacs lose response

[Leo]

On Sat, 09/23/2006 19:18 +0100, Chong Yidong wrote:

> 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?

The ChangeLog says it's fixed. But I can't see the actually
fix. gnus-demon.el has not been changed for 7 month.

-- 
Leo

Re: gnus makes emacs lose response

[Chong Yidong]

Leo <sdl.web@gmail.com> writes:

> The ChangeLog says it's fixed. But I can't see the actually
> fix. gnus-demon.el has not been changed for 7 month.

Hmm, I could have sworn I checked it in; oh well. I really did check
it in this time.

Re: gnus makes emacs lose response

[Leo]

On Tue, 09/26/2006 19:08 +0100, Chong Yidong wrote:

> Leo <sdl.web@gmail.com> writes:
>
>> The ChangeLog says it's fixed. But I can't see the actually
>> fix. gnus-demon.el has not been changed for 7 month.
>
> Hmm, I could have sworn I checked it in; oh well. I really did check
> it in this time.

Thanks.

I can see the change now.

-- 
Leo

Re: gnus makes emacs lose response

[Kim F. Storm]

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

Re: gnus makes emacs lose response

[Stefan Monnier]

> (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?


        Stefan

Re: gnus makes emacs lose response

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> 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?

Re: gnus makes emacs lose response

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> 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?

Which patch are you referring to here?

Re: gnus makes emacs lose response

[Chong Yidong]

> Stefan Monnier <monnier@iro.umontreal.ca> 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?
>
> Which patch are you referring to here?

OK I found it.

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

Stefan, why do you check read_kbd with PROCESSP?  read_kbd is an
integer (0 in this case), not a process.  Shouldn't it be

    +  if (time_limit == 0 && read_kbd == 0 && !NILP (Vinhibit_quit))
    +    error ("Blocking call to accept-process-output with quit inhibited!!");

Re: gnus makes emacs lose response

[Stefan Monnier]

> Stefan, why do you check read_kbd with PROCESSP?

Hmm.... beats me!

> read_kbd is an
> integer (0 in this case), not a process.  Shouldn't it be

Oh I see, it's because I haven't updated the code in response to the
following change:

2004-08-19  Kim F. Storm  <storm@cua.dk>

	* process.c (wait_reading_process_input): Clean up.
	Add wait_for_cell, wait_proc, and just_wait_proc args
	to avoid overloading `read_kbd' and `do_display' args.
	Change read_kbd arg to int.  All callers changed.

So I should probably check wait_proc instead.


        Stefan

Re: gnus makes emacs lose response

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Oh I see, it's because I haven't updated the code in response to the
> following change:
>
> 2004-08-19  Kim F. Storm  <storm@cua.dk>
>
> 	* process.c (wait_reading_process_input): Clean up.
> 	Add wait_for_cell, wait_proc, and just_wait_proc args
> 	to avoid overloading `read_kbd' and `do_display' args.
> 	Change read_kbd arg to int.  All callers changed.
>
> So I should probably check wait_proc instead.

Could you post a new patch for Leon to try?

Re: gnus makes emacs lose response

[Stefan Monnier]

>>>>> "Chong" == Chong Yidong <cyd@stupidchicken.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Oh I see, it's because I haven't updated the code in response to the
>> following change:
>> 
>> 2004-08-19  Kim F. Storm  <storm@cua.dk>
>> 
>> * process.c (wait_reading_process_input): Clean up.
>> Add wait_for_cell, wait_proc, and just_wait_proc args
>> to avoid overloading `read_kbd' and `do_display' args.
>> Change read_kbd arg to int.  All callers changed.
>> 
>> So I should probably check wait_proc instead.

> Could you post a new patch for Leon to try?

You mean like the patch below?


        Stefan


--- orig/src/process.c
+++ mod/src/process.c
@@ -4259,6 +4260,9 @@
   FD_ZERO (&Connecting);
 #endif
 
+  if (time_limit == 0 && wait_proc && !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);

Re: gnus makes emacs lose response

[Richard Stallman]

    You mean like the patch below?

Should that patch be installed?

Re: gnus makes emacs lose response

[Richard Stallman]

    Oh I see, it's because I haven't updated the code in response to the
    following change:

    2004-08-19  Kim F. Storm  <storm@cua.dk>

	    * process.c (wait_reading_process_input): Clean up.
	    Add wait_for_cell, wait_proc, and just_wait_proc args
	    to avoid overloading `read_kbd' and `do_display' args.
	    Change read_kbd arg to int.  All callers changed.

    So I should probably check wait_proc instead.

Would you please make whatever change is needed?

Re: gnus makes emacs lose response

[Stefan Monnier]

>     Oh I see, it's because I haven't updated the code in response to the
>     following change:

>     2004-08-19  Kim F. Storm  <storm@cua.dk>

> 	    * process.c (wait_reading_process_input): Clean up.
> 	    Add wait_for_cell, wait_proc, and just_wait_proc args
> 	    to avoid overloading `read_kbd' and `do_display' args.
> 	    Change read_kbd arg to int.  All callers changed.

>     So I should probably check wait_proc instead.

> Would you please make whatever change is needed?

We're talking about a local change which I have no intention to install in
Emacs-CVS, or at least not for Emacs-22.  Although maybe it could be
added but controlled by a compilation flag such as ENABLE_CHECKING
or DEBUG.


        Stefan

Re: gnus makes emacs lose response

[Stefan Monnier]

>>>>> "Chong" == Chong Yidong <cyd@stupidchicken.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> 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?

> Which patch are you referring to here?

The one below, which I sent at the beginning of this thread.


        Stefan


--- orig/src/process.c
+++ mod/src/process.c
@@ -4259,6 +4260,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);

Re: gnus makes emacs lose response

[Kim F. Storm]

Leon <sdl.web@gmail.com> writes:

> I'm not sure if anybody is looking into this issue. Just want to
> double confirm that this bug exists and causes a lot of trouble when
> using shaky wireless network.

> GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.8.15) of
> 2006-03-25 on sl392

I installed a fix to the CVS trunk (22.x) on 2006-03-22 that may have
fixed this problem (it corrected an rather severe issue with the
timeout of accept-process-output).

According to the CVS log, that change was merged to the unicode branch
(23.x) on 2006-03-28, i.e. after your emacs was built.  Can you please
try with an up-to-date build, and tell us if the problem is still
there.  Thanks.

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

Re: gnus makes emacs lose response

[Leon]

storm@cua.dk (Kim F. Storm) writes:

> Leon <sdl.web@gmail.com> writes:
>
>> I'm not sure if anybody is looking into this issue. Just want to
>> double confirm that this bug exists and causes a lot of trouble when
>> using shaky wireless network.
>
>> GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.8.15) of
>> 2006-03-25 on sl392
>
> I installed a fix to the CVS trunk (22.x) on 2006-03-22 that may have
> fixed this problem (it corrected an rather severe issue with the
> timeout of accept-process-output).
>
> According to the CVS log, that change was merged to the unicode branch
> (23.x) on 2006-03-28, i.e. after your emacs was built.  Can you please
> try with an up-to-date build, and tell us if the problem is still
> there.  Thanks.

Unfortunately, it has not been fixed up to today's CVS. How can I
generate debug messages? Thank you.

-- 
Leon
Emacs:GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.8.15) of
2006-04-05 on sl392

Re: gnus makes emacs lose response

[Kim F. Storm]

Leon <sdl.web@gmail.com> writes:

> Unfortunately, it has not been fixed up to today's CVS. How can I
> generate debug messages? Thank you.

You should run emacs under a debugger
    cd emacs/src
    gdb emacs
    r

When it hangs, stop it

    C-z

then examine the stack and other stuff to see
where it hangs, e.g. as a first step, send us
the output from these commands:

    bt
    xba
    bt full

Please read etc/DEBUG for info on debugging emacs.

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

Re: gnus makes emacs lose response

[Leon]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

storm@cua.dk (Kim F. Storm) writes:

> Leon <sdl.web@gmail.com> writes:
>
>> Unfortunately, it has not been fixed up to today's CVS. How can I
>> generate debug messages? Thank you.
>
> You should run emacs under a debugger
>     cd emacs/src
>     gdb emacs
>     r
>
> When it hangs, stop it
>
>     C-z
>
> then examine the stack and other stuff to see
> where it hangs, e.g. as a first step, send us
> the output from these commands:
>
>     bt
>     xba
>     bt full
>
> Please read etc/DEBUG for info on debugging emacs.
It seems when I compiled emacs I didn't turn on debug. I have followed
your instruction and get some debug info attached.


[-- Attachment #2: backtrace --]
[-- Type: text/plain, Size: 3549 bytes --]

GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
Copyright 2004 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"...
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".

DISPLAY = :0.0
TERM = xterm
.gdbinit:834: Error in sourced command file:
No struct type named Lisp_Symbol.
(gdb) r
Starting program: /home/b/emacs/src/emacs-23.0.0 -geometry 80x40+0+0
Reading symbols from shared object read from target memory...(no debugging symbols found)...done.
Loaded system supplied DSO at 0x55b000
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1208699216 (LWP 2669)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
Detaching after fork from child process 2672.
Detaching after fork from child process 2674.
---Type <return> to continue, or q <return> to quit---
Detaching after fork from child process 2675.
Detaching after fork from child process 2677.
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGTSTP, Stopped (user).
[Switching to Thread -1208699216 (LWP 2669)]
0x0055b402 in __kernel_vsyscall ()
(gdb) bt
#0  0x0055b402 in __kernel_vsyscall ()
#1  0x0063a53d in ___newselect_nocancel () from /lib/libc.so.6
#2  0x0819b11e in wait_reading_process_output ()
#3  0xbfa5fc38 in ?? ()
#4  0x00000000 in ?? ()

Lisp Backtrace:
Attempt to extract a component of a value that is not a structure pointer.
(gdb) xba
Attempt to extract a component of a value that is not a structure pointer.
(gdb) bt full
#0  0x0055b402 in __kernel_vsyscall ()
No symbol table info available.
#1  0x0063a53d in ___newselect_nocancel () from /lib/libc.so.6
No symbol table info available.
#2  0x0819b11e in wait_reading_process_output ()
No symbol table info available.
#3  0xbfa5fc38 in ?? ()
No symbol table info available.
#4  0x00000000 in ?? ()
No symbol table info available.

Lisp Backtrace:
Attempt to extract a component of a value that is not a structure pointer.
(gdb)


[-- Attachment #3: Type: text/plain, Size: 115 bytes --]


Thank you, Kim.
-- 
Leon
Emacs:GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.8.15) of
2006-04-05 on sl392

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: gnus makes emacs lose response

[Kim F. Storm]

Leon <sdl.web@gmail.com> writes:

> It seems when I compiled emacs I didn't turn on debug. I have followed
> your instruction and get some debug info attached.
>

Thanks, but...
.. without debugging information, the output from those commands
is inadequate to diagnose the problem.

> #0  0x0055b402 in __kernel_vsyscall ()
> #1  0x0063a53d in ___newselect_nocancel () from /lib/libc.so.6
> #2  0x0819b11e in wait_reading_process_output ()

This is "near the spot" where I made the fix I mentioned.
Maybe that fix isn't in your sources.  A simple way to check:

If you do C-h C-f accept-process-output, do you get this result
[check that the arguments are named SECONDS and MILLISEC] ??


accept-process-output is a built-in function in `C source code'.
(accept-process-output &optional process seconds millisec
just-this-one)

Allow any pending output from subprocesses to be read by Emacs.
It is read into the process' buffers or given to their filter functions.
Non-nil arg process means do not return until some output has been received
from process.

Non-nil second arg seconds and third arg millisec are number of
seconds and milliseconds to wait; return after that much time whether
or not there is input.  If seconds is a floating point number,
it specifies a fractional number of seconds to wait.

If optional fourth arg just-this-one is non-nil, only accept output
from process, suspending reading output from other processes.
If just-this-one is an integer, don't run any timers either.
Return non-nil iff we received any output before the timeout expired.


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

Re: gnus makes emacs lose response

[Leon]

storm@cua.dk (Kim F. Storm) writes:

> Leon <sdl.web@gmail.com> writes:
>
>> It seems when I compiled emacs I didn't turn on debug. I have followed
>> your instruction and get some debug info attached.
>>
>
> Thanks, but...
> .. without debugging information, the output from those commands
> is inadequate to diagnose the problem.
>

How can compile with debug information? I'll try to re-compile in a
week!

>> #0  0x0055b402 in __kernel_vsyscall ()
>> #1  0x0063a53d in ___newselect_nocancel () from /lib/libc.so.6
>> #2  0x0819b11e in wait_reading_process_output ()
>
> This is "near the spot" where I made the fix I mentioned.
> Maybe that fix isn't in your sources.  A simple way to check:
>
> If you do C-h C-f accept-process-output, do you get this result
> [check that the arguments are named SECONDS and MILLISEC] ??
>

Seems it's in my source.

,--------[ C-h f accept-process-output ]
| accept-process-output is a built-in function in `C source code'.
| (accept-process-output &optional PROCESS SECONDS MILLISEC
| JUST-THIS-ONE)
| 
| Allow any pending output from subprocesses to be read by Emacs.
| It is read into the process' buffers or given to their filter functions.
| Non-nil arg PROCESS means do not return until some output has been received
| from PROCESS.
| 
| Non-nil second arg SECONDS and third arg MILLISEC are number of
| seconds and milliseconds to wait; return after that much time whether
| or not there is input.  If SECONDS is a floating point number,
| it specifies a fractional number of seconds to wait.
| 
| If optional fourth arg JUST-THIS-ONE is non-nil, only accept output
| from PROCESS, suspending reading output from other processes.
| If JUST-THIS-ONE is an integer, don't run any timers either.
| Return non-nil iff we received any output before the timeout expired.
| 
| [back]
`--------

>
> accept-process-output is a built-in function in `C source code'.
> (accept-process-output &optional process seconds millisec
> just-this-one)
>
> Allow any pending output from subprocesses to be read by Emacs.
> It is read into the process' buffers or given to their filter functions.
> Non-nil arg process means do not return until some output has been received
> from process.
>
> Non-nil second arg seconds and third arg millisec are number of
> seconds and milliseconds to wait; return after that much time whether
> or not there is input.  If seconds is a floating point number,
> it specifies a fractional number of seconds to wait.
>
> If optional fourth arg just-this-one is non-nil, only accept output
> from process, suspending reading output from other processes.
> If just-this-one is an integer, don't run any timers either.
> Return non-nil iff we received any output before the timeout expired.

Thank you for explaining this.

-- 
Leon

Re: gnus makes emacs lose response

[Ralf Angeli]

* Kim F. Storm (2006-04-06) writes:

> then examine the stack and other stuff to see
> where it hangs, e.g. as a first step, send us
> the output from these commands:
>
>     bt
>     xba
>     bt full

How 'bout that? (All strings replaced with "[...]" because I was not
sure if they contained stuff like passwords.)

(gdb) r
Starting program: /usr/src/emacs/src/emacs -geometry 80x40+0+0
[Thread debugging using libthread_db enabled]
[New Thread -1486387520 (LWP 7164)]
[Switching to Thread -1486387520 (LWP 7164)]
Breakpoint 3 at 0x80cf77c: file xterm.c, line 7813.

Program received signal SIGTSTP, Stopped (user).
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xa77f7d2d in select () from /lib/tls/i686/cmov/libc.so.6
#2  0x0819228b in wait_reading_process_output (time_limit=0, microsecs=100000, 
    read_kbd=0, do_display=0, wait_for_cell=137558217, wait_proc=0x8b7ada8, 
    just_wait_proc=0) at process.c:4494
#3  0x08193f5a in Faccept_process_output (process=146255276, seconds=0, 
    millisec=100, just_this_one=137558217) at process.c:3893
#4  0x0815dc3a in Ffuncall (nargs=4, args=0xaffc1cc0) at eval.c:2911
#5  0x0818ab27 in Fbyte_code (bytestr=146094019, vector=146096036, maxdepth=8)
    at bytecode.c:694
#6  0x0815d5ee in funcall_lambda (fun=146096252, nargs=2, 
    arg_vector=0xaffc1df4) at eval.c:3088
#7  0x0815db09 in Ffuncall (nargs=3, args=0xaffc1df0) at eval.c:2956
#8  0x0818ab27 in Fbyte_code (bytestr=146175931, vector=146193772, maxdepth=8)
    at bytecode.c:694
#9  0x0815d5ee in funcall_lambda (fun=146194132, nargs=2, 
    arg_vector=0xaffc1f24) at eval.c:3088
#10 0x0815db09 in Ffuncall (nargs=3, args=0xaffc1f20) at eval.c:2956
#11 0x0818ab27 in Fbyte_code (bytestr=142955195, vector=143969076, maxdepth=7)
    at bytecode.c:694
#12 0x0815d5ee in funcall_lambda (fun=143969292, nargs=2, 
    arg_vector=0xaffc2054) at eval.c:3088
#13 0x0815db09 in Ffuncall (nargs=3, args=0xaffc2050) at eval.c:2956
---Type <return> to continue, or q <return> to quit---
#14 0x0818ab27 in Fbyte_code (bytestr=144102571, vector=144105388, maxdepth=6)
    at bytecode.c:694
#15 0x0815d5ee in funcall_lambda (fun=144105556, nargs=2, 
    arg_vector=0xaffc2184) at eval.c:3088
#16 0x0815db09 in Ffuncall (nargs=3, args=0xaffc2180) at eval.c:2956
#17 0x0818ab27 in Fbyte_code (bytestr=144102315, vector=144103916, maxdepth=6)
    at bytecode.c:694
#18 0x0815d5ee in funcall_lambda (fun=144104276, nargs=2, 
    arg_vector=0xaffc22b4) at eval.c:3088
#19 0x0815db09 in Ffuncall (nargs=3, args=0xaffc22b0) at eval.c:2956
#20 0x0818ab27 in Fbyte_code (bytestr=144102219, vector=144103484, maxdepth=5)
    at bytecode.c:694
#21 0x0815d5ee in funcall_lambda (fun=144103676, nargs=0, 
    arg_vector=0xaffc23e4) at eval.c:3088
#22 0x0815db09 in Ffuncall (nargs=1, args=0xaffc23e0) at eval.c:2956
#23 0x0818ab27 in Fbyte_code (bytestr=143864939, vector=143869220, maxdepth=3)
    at bytecode.c:694
#24 0x0815d5ee in funcall_lambda (fun=143869436, nargs=1, 
    arg_vector=0xaffc2574) at eval.c:3088
#25 0x0815db09 in Ffuncall (nargs=2, args=0xaffc2570) at eval.c:2956
#26 0x0815a1ec in Fcall_interactively (function=142776193, 
    record_flag=137558217, keys=137598716) at callint.c:884
#27 0x080fbb0d in Fcommand_execute (cmd=142776193, record_flag=137558217, 
---Type <return> to continue, or q <return> to quit---
    keys=-514, special=137558217) at keyboard.c:9759
#28 0x081044b8 in command_loop_1 () at keyboard.c:1791
#29 0x0815bee2 in internal_condition_case (bfun=0x8104160 <command_loop_1>, 
    handlers=137602857, hfun=0x80fc610 <cmd_error>) at eval.c:1473
#30 0x080f699e in command_loop_2 () at keyboard.c:1328
#31 0x0815bbbc in internal_catch (tag=-514, func=0x80f6970 <command_loop_2>, 
    arg=137558217) at eval.c:1211
#32 0x080f677e in command_loop () at keyboard.c:1307
#33 0x080f6824 in recursive_edit_1 () at keyboard.c:1000
#34 0x080f6930 in Frecursive_edit () at keyboard.c:1061
#35 0x080f58be in main (argc=3, argv=0xaffc2e54) at emacs.c:1789

Lisp Backtrace:
"accept-process-output"
"imap-wait-for-tag"
"nnimap-retrieve-groups"
"gnus-retrieve-groups"
"gnus-read-active-file-2"
"gnus-read-active-file-1"
"gnus-read-active-file"
"gnus-group-get-new-news"
"call-interactively"
(gdb) xba
"accept-process-output"
"imap-wait-for-tag"
"nnimap-retrieve-groups"
"gnus-retrieve-groups"
"gnus-read-active-file-2"
"gnus-read-active-file-1"
"gnus-read-active-file"
"gnus-group-get-new-news"
"call-interactively"
(gdb) bt full
#0  0xffffe410 in __kernel_vsyscall ()
No symbol table info available.
#1  0xa77f7d2d in select () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#2  0x0819228b in wait_reading_process_output (time_limit=0, microsecs=100000, 
    read_kbd=0, do_display=0, wait_for_cell=137558217, wait_proc=0x8b7ada8, 
    just_wait_proc=0) at process.c:4494
        Atemp = {
  fds_bits = {48, 48, 400, 148630114, 2, 0, 1, 48, 146255272, 400, 0, 
    148630172, 146255276, 135672289, 48, 48, 135049360, 146328635, 137269152, 
    -1342432636, -1342432760, 135871880, 146328619, 2, -1342432728, 3, 
    145778830, -1342432636, -1342432664, 135650297, 146255276, 146328635}
}
        Ctemp = {
  fds_bits = {0 <repeats 25 times>, 268435456, 48, 48, -1342432792, 135869785, 
    13, 135049360}
}
        timeout_reduced_for_timers = 0
        channel = <value optimized out>
        nfds = 0
        Available = {
  fds_bits = {256, 0 <repeats 31 times>}
}
---Type <return> to continue, or q <return> to quit---
        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 = 88000
}
        end_time = {
  tv_sec = 1144441079, 
  tv_usec = 90100
}
        wait_channel = 8
        got_some_input = 0
        saved_waiting_for_user_input_p = 0
#3  0x08193f5a in Faccept_process_output (process=146255276, seconds=0, 
    millisec=100, just_this_one=137558217) at process.c:3893
        carry = <value optimized out>
        secs = 0
---Type <return> to continue, or q <return> to quit---
        usecs = -1342432616
#4  0x0815dc3a in Ffuncall (nargs=4, args=0xaffc1cc0) at eval.c:2911
        fun = <value optimized out>
        funcar = <value optimized out>
        numargs = 3
        val = <value optimized out>
        backtrace = {
  next = 0xaffc1db8, 
  function = 0xaffc1cc0, 
  args = 0xaffc1cc4, 
  nargs = 3, 
  evalargs = 0 '\0', 
  debug_on_exit = 0 '\0'
}
        internal_args = (Lisp_Object *) 0xaffc1c50
        i = 0
#5  0x0818ab27 in Fbyte_code (bytestr=146094019, vector=146096036, maxdepth=8)
    at bytecode.c:694
        v1 = 50
        v2 = <value optimized out>
        op = <value optimized out>
        vectorp = (Lisp_Object *) 0x8b53fa8
        stack = {
---Type <return> to continue, or q <return> to quit---
  pc = 0x8b06a58 "[...]", 
  top = 0xaffc1ccc, 
  bottom = 0xaffc1cc0, 
  byte_string = 146094019, 
  byte_string_start = 0x8b06a14 "[...]", 
  constants = 146096036, 
  next = 0xaffc1e40
}
        top = (Lisp_Object *) 0xaffc1cc0
        result = <value optimized out>
#6  0x0815d5ee in funcall_lambda (fun=146096252, nargs=2, 
    arg_vector=0xaffc1df4) at eval.c:3088
        val = <value optimized out>
        syms_left = <value optimized out>
        next = <value optimized out>
        i = 2
        optional = 1
        rest = 0
#7  0x0815db09 in Ffuncall (nargs=3, args=0xaffc1df0) at eval.c:2956
        fun = 146096252
        funcar = <value optimized out>
        numargs = 2
        val = <value optimized out>
---Type <return> to continue, or q <return> to quit---
        backtrace = {
  next = 0xaffc1ee8, 
  function = 0xaffc1df0, 
  args = 0xaffc1df4, 
  nargs = 2, 
  evalargs = 0 '\0', 
  debug_on_exit = 0 '\0'
}
        internal_args = (Lisp_Object *) 0xaffc1df4
        i = <value optimized out>
#8  0x0818ab27 in Fbyte_code (bytestr=146175931, vector=146193772, maxdepth=8)
    at bytecode.c:694
        v1 = 245
        v2 = <value optimized out>
        op = <value optimized out>
        vectorp = (Lisp_Object *) 0x8b6bd70
        stack = {
  pc = 0x8ae2fe6 "[...]", 
  top = 0xaffc1df8, 
  bottom = 0xaffc1df0, 
  byte_string = 146175931, 
  byte_string_start = 0x8ae2f54 "[...]", 
---Type <return> to continue, or q <return> to quit---
  constants = 146193772, 
  next = 0xaffc1f70
}
        top = (Lisp_Object *) 0xaffc1df0
        result = <value optimized out>
#9  0x0815d5ee in funcall_lambda (fun=146194132, nargs=2, 
    arg_vector=0xaffc1f24) at eval.c:3088
        val = <value optimized out>
        syms_left = <value optimized out>
        next = <value optimized out>
        i = 2
        optional = 1
        rest = 0
#10 0x0815db09 in Ffuncall (nargs=3, args=0xaffc1f20) at eval.c:2956
        fun = 146194132
        funcar = <value optimized out>
        numargs = 2
        val = <value optimized out>
        backtrace = {
  next = 0xaffc2018, 
  function = 0xaffc1f20, 
  args = 0xaffc1f24, 
  nargs = 2, 
---Type <return> to continue, or q <return> to quit---
  evalargs = 0 '\0', 
  debug_on_exit = 0 '\0'
}
        internal_args = (Lisp_Object *) 0xaffc1f24
        i = <value optimized out>
#11 0x0818ab27 in Fbyte_code (bytestr=142955195, vector=143969076, maxdepth=7)
    at bytecode.c:694
        v1 = 176
        v2 = <value optimized out>
        op = <value optimized out>
        vectorp = (Lisp_Object *) 0x894cb38
        stack = {
  pc = 0x88f4cca "[...]", 
  top = 0xaffc1f28, 
  bottom = 0xaffc1f20, 
  byte_string = 142955195, 
  byte_string_start = 0x88f4c10 "[...]", 
  constants = 143969076, 
  next = 0xaffc20a0
}
        top = (Lisp_Object *) 0xaffc1f20
        result = <value optimized out>
#12 0x0815d5ee in funcall_lambda (fun=143969292, nargs=2, 
---Type <return> to continue, or q <return> to quit---
    arg_vector=0xaffc2054) at eval.c:3088
        val = <value optimized out>
        syms_left = <value optimized out>
        next = <value optimized out>
        i = 2
        optional = 0
        rest = 0
#13 0x0815db09 in Ffuncall (nargs=3, args=0xaffc2050) at eval.c:2956
        fun = 143969292
        funcar = <value optimized out>
        numargs = 2
        val = <value optimized out>
        backtrace = {
  next = 0xaffc2148, 
  function = 0xaffc2050, 
  args = 0xaffc2054, 
  nargs = 2, 
  evalargs = 0 '\0', 
  debug_on_exit = 0 '\0'
}
        internal_args = (Lisp_Object *) 0xaffc2054
        i = <value optimized out>
#14 0x0818ab27 in Fbyte_code (bytestr=144102571, vector=144105388, maxdepth=6)
---Type <return> to continue, or q <return> to quit---
    at bytecode.c:694
        v1 = 51
        v2 = <value optimized out>
        op = <value optimized out>
        vectorp = (Lisp_Object *) 0x896dfb0
        stack = {
  pc = 0x88a65b8 "[...]", 
  top = 0xaffc2058, 
  bottom = 0xaffc2050, 
  byte_string = 144102571, 
  byte_string_start = 0x88a65a8 "[...]", 
  constants = 144105388, 
  next = 0xaffc21d0
}
        top = (Lisp_Object *) 0xaffc2050
        result = <value optimized out>
#15 0x0815d5ee in funcall_lambda (fun=144105556, nargs=2, 
    arg_vector=0xaffc2184) at eval.c:3088
        val = <value optimized out>
        syms_left = <value optimized out>
        next = <value optimized out>
        i = 2
        optional = 0
---Type <return> to continue, or q <return> to quit---
        rest = 0
#16 0x0815db09 in Ffuncall (nargs=3, args=0xaffc2180) at eval.c:2956
        fun = 144105556
        funcar = <value optimized out>
        numargs = 2
        val = <value optimized out>
        backtrace = {
  next = 0xaffc2278, 
  function = 0xaffc2180, 
  args = 0xaffc2184, 
  nargs = 2, 
  evalargs = 0 '\0', 
  debug_on_exit = 0 '\0'
}
        internal_args = (Lisp_Object *) 0xaffc2184
        i = <value optimized out>
#17 0x0818ab27 in Fbyte_code (bytestr=144102315, vector=144103916, maxdepth=6)
    at bytecode.c:694
        v1 = 461
        v2 = <value optimized out>
        op = <value optimized out>
        vectorp = (Lisp_Object *) 0x896d9f0
        stack = {
---Type <return> to continue, or q <return> to quit---
  pc = 0x88a6452 "[...]", 
  top = 0xaffc2188, 
  bottom = 0xaffc2180, 
  byte_string = 144102315, 
  byte_string_start = 0x88a6280 "[...]", 
  constants = 144103916, 
  next = 0xaffc2300
}
        top = (Lisp_Object *) 0xaffc2180
        result = <value optimized out>
#18 0x0815d5ee in funcall_lambda (fun=144104276, nargs=2, 
    arg_vector=0xaffc22b4) at eval.c:3088
        val = <value optimized out>
        syms_left = <value optimized out>
        next = <value optimized out>
        i = 2
        optional = 0
        rest = 0
#19 0x0815db09 in Ffuncall (nargs=3, args=0xaffc22b0) at eval.c:2956
        fun = 144104276
        funcar = <value optimized out>
---Type <return> to continue, or q <return> to quit---
        numargs = 2
        val = <value optimized out>
        backtrace = {
  next = 0xaffc23a8, 
  function = 0xaffc22b0, 
  args = 0xaffc22b4, 
  nargs = 2, 
  evalargs = 0 '\0', 
  debug_on_exit = 0 '\0'
}
        internal_args = (Lisp_Object *) 0xaffc22b4
        i = <value optimized out>
#20 0x0818ab27 in Fbyte_code (bytestr=144102219, vector=144103484, maxdepth=5)
    at bytecode.c:694
        v1 = 68
        v2 = <value optimized out>
        op = <value optimized out>
        vectorp = (Lisp_Object *) 0x896d840
        stack = {
  pc = 0x88a61c9 "[...]", 
  top = 0xaffc22b8, 
  bottom = 0xaffc22b0, 
  byte_string = 144102219, 
---Type <return> to continue, or q <return> to quit---
  byte_string_start = 0x88a6180 "[...]", 
  constants = 144103484, 
  next = 0xaffc2420
}
        top = (Lisp_Object *) 0xaffc22b0
        result = <value optimized out>
#21 0x0815d5ee in funcall_lambda (fun=144103676, nargs=0, 
    arg_vector=0xaffc23e4) at eval.c:3088
        val = <value optimized out>
        syms_left = <value optimized out>
        next = <value optimized out>
        i = 0
        optional = 1
        rest = 0
#22 0x0815db09 in Ffuncall (nargs=1, args=0xaffc23e0) at eval.c:2956
        fun = 144103676
        funcar = <value optimized out>
        numargs = 0
        val = <value optimized out>
        backtrace = {
  next = 0xaffc24c8, 
  function = 0xaffc23e0, 
  args = 0xaffc23e4, 
---Type <return> to continue, or q <return> to quit---
  nargs = 0, 
  evalargs = 0 '\0', 
  debug_on_exit = 0 '\0'
}
        internal_args = (Lisp_Object *) 0xaffc23e4
        i = <value optimized out>
#23 0x0818ab27 in Fbyte_code (bytestr=143864939, vector=143869220, maxdepth=3)
    at bytecode.c:694
        v1 = 101
        v2 = <value optimized out>
        op = <value optimized out>
        vectorp = (Lisp_Object *) 0x8934528
        stack = {
  pc = 0x89ba169 "[...]", 
  top = 0xaffc23e0, 
  bottom = 0xaffc23e0, 
  byte_string = 143864939, 
  byte_string_start = 0x89ba10c "[...]", 
  constants = 143869220, 
  next = 0x0
}
        top = (Lisp_Object *) 0xaffc23e0
---Type <return> to continue, or q <return> to quit---
        result = <value optimized out>
#24 0x0815d5ee in funcall_lambda (fun=143869436, nargs=1, 
    arg_vector=0xaffc2574) at eval.c:3088
        val = <value optimized out>
        syms_left = <value optimized out>
        next = <value optimized out>
        i = 1
        optional = 1
        rest = 0
#25 0x0815db09 in Ffuncall (nargs=2, args=0xaffc2570) at eval.c:2956
        fun = 143869436
        funcar = <value optimized out>
        numargs = 1
        val = <value optimized out>
        backtrace = {
  next = 0xaffc2718, 
  function = 0xaffc2570, 
  args = 0xaffc2574, 
  nargs = 1, 
  evalargs = 0 '\0', 
  debug_on_exit = 0 '\0'
}
        internal_args = (Lisp_Object *) 0xaffc2574
---Type <return> to continue, or q <return> to quit---
        i = <value optimized out>
#26 0x0815a1ec in Fcall_interactively (function=142776193, 
    record_flag=137558217, keys=137598716) at callint.c:884
        val = <value optimized out>
        fun = <value optimized out>
        specs = 143864955
        teml = <value optimized out>
        up_event = 137558217
        enable = 137558217
        next_event = 0
        prefix_arg = 137558217
        string = <value optimized out>
        tem = (unsigned char *) 0x81b8871 ""
        i = <value optimized out>
        j = 1
        foo = <value optimized out>
        prompt1 = '\0' <repeats 99 times>
        arg_from_tty = 0
        key_count = 1
        record_then_fail = 0
        save_this_command = 142776193
        save_last_command = 143673529
        save_this_original_command = 142776193
---Type <return> to continue, or q <return> to quit---
        save_real_this_command = 142776193
#27 0x080fbb0d in Fcommand_execute (cmd=142776193, record_flag=137558217, 
    keys=-514, special=137558217) at keyboard.c:9759
        final = 143869436
        tem = <value optimized out>
        prefixarg = 137558217
        backtrace = {
  next = 0x0, 
  function = 0x8322670, 
  args = 0xaffc2740, 
  nargs = 1, 
  evalargs = 0 '\0', 
  debug_on_exit = 0 '\0'
}
#28 0x081044b8 in command_loop_1 () at keyboard.c:1791
        cmd = <value optimized out>
        lose = <value optimized out>
        nonundocount = 0
        keybuf = {824, 848, -1483884048, -1342429284, -1476678818, 134536200, 
  -1483884036, -1476636684, 9287600, -1483883960, -1342429196, -1476698759, 
  -1485575509, 134537900, 0, 0, 134526604, 110932256, 134537597, 0, 
  -1342429224, -1342429376, 0, -1485635584, 137558217, 139268593, 0, 1, 1, 
  -1342429192}
---Type <return> to continue, or q <return> to quit---
        i = 1
        prev_modiff = 1176
        prev_buffer = (struct buffer *) 0x8867238
        was_locked = 0
        already_adjusted = <value optimized out>
#29 0x0815bee2 in internal_condition_case (bfun=0x8104160 <command_loop_1>, 
    handlers=137602857, hfun=0x80fc610 <cmd_error>) at eval.c:1473
        val = <value optimized out>
        c = {
  tag = 137558217, 
  val = 137558217, 
  next = 0xaffc2920, 
  gcpro = 0x0, 
  jmp = {{
      __jmpbuf = {0, 1, 1, -1342428952, -1342429184, 135642787}, 
      __mask_was_saved = 0, 
      __saved_mask = {
        __val = {0, 2952538336, 2818331912, 134537597, 110932256, 16777216, 
          0 <repeats 21 times>, 2809367228, 2811083336, 2818330612, 
          2818331912, 1}
      }
    }}, 
  backlist = 0x0, 
---Type <return> to continue, or q <return> to quit---
  handlerlist = 0x0, 
  lisp_eval_depth = 0, 
  pdlcount = 2, 
  poll_suppress_count = 1, 
  interrupt_input_blocked = 0, 
  byte_stack = 0x0
}
        h = {
  handler = 137602857, 
  var = 137558217, 
  chosen_clause = 136030732, 
  tag = 0xaffc280c, 
  next = 0x0
}
#30 0x080f699e in command_loop_2 () at keyboard.c:1328
        val = <value optimized out>
#31 0x0815bbbc in internal_catch (tag=-514, func=0x80f6970 <command_loop_2>, 
    arg=137558217) at eval.c:1211
        c = {
  tag = 137599089, 
  val = 137558217, 
  next = 0x0, 
  gcpro = 0x0, 
---Type <return> to continue, or q <return> to quit---
  jmp = {{
      __jmpbuf = {0, 1, 1, -1342428696, -1342428912, 135642031}, 
      __mask_was_saved = 0, 
      __saved_mask = {
        __val = {0, 0, 139993024, 12, 12, 2952538152, 135555972, 139993024, 
          12, 12, 12, 2952538436, 137743378, 137740448, 137740449, 2952538568, 
          135575905, 137740449, 137743378, 137558217, 137590072, 1, 137590072, 
          137558217, 137558241, 2, 137743376, 2952538584, 137740448, 
          137740449, 0, 2952538632}
      }
    }}, 
  backlist = 0x0, 
  handlerlist = 0x0, 
  lisp_eval_depth = 0, 
  pdlcount = 2, 
  poll_suppress_count = 1, 
  interrupt_input_blocked = 0, 
  byte_stack = 0x0
}
#32 0x080f677e in command_loop () at keyboard.c:1307
No locals.
#33 0x080f6824 in recursive_edit_1 () at keyboard.c:1000
        val = <value optimized out>
---Type <return> to continue, or q <return> to quit---
#34 0x080f6930 in Frecursive_edit () at keyboard.c:1061
        buffer = <value optimized out>
#35 0x080f58be in main (argc=3, argv=0xaffc2e54) at emacs.c:1789
        tz = 0x0
        dummy = -1342427688
        stack_bottom_variable = 8 '\b'
        do_initial_setlocale = 1
        skip_args = 0
        rlim = {
  rlim_cur = 8388608, 
  rlim_max = 18446744073709551615
}
        no_loadup = 0
        junk = 0x0

Lisp Backtrace:
"accept-process-output"
"imap-wait-for-tag"
"nnimap-retrieve-groups"
"gnus-retrieve-groups"
"gnus-read-active-file-2"
"gnus-read-active-file-1"
"gnus-read-active-file"
---Type <return> to continue, or q <return> to quit---
"gnus-group-get-new-news"
"call-interactively"

-- 
Ralf

Re: gnus makes emacs lose response

[Leon]

Thank you, Ralf. Hope someone and fix the bug based on your post!

Ralf Angeli <angeli@iwi.uni-sb.de> writes:

> * Kim F. Storm (2006-04-06) writes:
>
>> then examine the stack and other stuff to see
>> where it hangs, e.g. as a first step, send us
>> the output from these commands:
>>
>>     bt
>>     xba
>>     bt full
>
> How 'bout that? (All strings replaced with "[...]" because I was not
> sure if they contained stuff like passwords.)
>
> (gdb) r
> Starting program: /usr/src/emacs/src/emacs -geometry 80x40+0+0
> [Thread debugging using libthread_db enabled]
> [New Thread -1486387520 (LWP 7164)]
> [Switching to Thread -1486387520 (LWP 7164)]
> Breakpoint 3 at 0x80cf77c: file xterm.c, line 7813.
>
> Program received signal SIGTSTP, Stopped (user).
> 0xffffe410 in __kernel_vsyscall ()
> (gdb) bt
> #0  0xffffe410 in __kernel_vsyscall ()
> #1  0xa77f7d2d in select () from /lib/tls/i686/cmov/libc.so.6
> #2  0x0819228b in wait_reading_process_output (time_limit=0, microsecs=100000, 
>     read_kbd=0, do_display=0, wait_for_cell=137558217, wait_proc=0x8b7ada8, 
>     just_wait_proc=0) at process.c:4494
> #3  0x08193f5a in Faccept_process_output (process=146255276, seconds=0, 
>     millisec=100, just_this_one=137558217) at process.c:3893
> #4  0x0815dc3a in Ffuncall (nargs=4, args=0xaffc1cc0) at eval.c:2911
> #5  0x0818ab27 in Fbyte_code (bytestr=146094019, vector=146096036, maxdepth=8)
>     at bytecode.c:694
> #6  0x0815d5ee in funcall_lambda (fun=146096252, nargs=2, 
>     arg_vector=0xaffc1df4) at eval.c:3088
> #7  0x0815db09 in Ffuncall (nargs=3, args=0xaffc1df0) at eval.c:2956
> #8  0x0818ab27 in Fbyte_code (bytestr=146175931, vector=146193772, maxdepth=8)
>     at bytecode.c:694
> #9  0x0815d5ee in funcall_lambda (fun=146194132, nargs=2, 
>     arg_vector=0xaffc1f24) at eval.c:3088
> #10 0x0815db09 in Ffuncall (nargs=3, args=0xaffc1f20) at eval.c:2956
> #11 0x0818ab27 in Fbyte_code (bytestr=142955195, vector=143969076, maxdepth=7)
>     at bytecode.c:694
> #12 0x0815d5ee in funcall_lambda (fun=143969292, nargs=2, 
>     arg_vector=0xaffc2054) at eval.c:3088
> #13 0x0815db09 in Ffuncall (nargs=3, args=0xaffc2050) at eval.c:2956
> ---Type <return> to continue, or q <return> to quit---
> #14 0x0818ab27 in Fbyte_code (bytestr=144102571, vector=144105388, maxdepth=6)
>     at bytecode.c:694
> #15 0x0815d5ee in funcall_lambda (fun=144105556, nargs=2, 
>     arg_vector=0xaffc2184) at eval.c:3088
> #16 0x0815db09 in Ffuncall (nargs=3, args=0xaffc2180) at eval.c:2956
> #17 0x0818ab27 in Fbyte_code (bytestr=144102315, vector=144103916, maxdepth=6)
>     at bytecode.c:694
> #18 0x0815d5ee in funcall_lambda (fun=144104276, nargs=2, 
>     arg_vector=0xaffc22b4) at eval.c:3088
> #19 0x0815db09 in Ffuncall (nargs=3, args=0xaffc22b0) at eval.c:2956
> #20 0x0818ab27 in Fbyte_code (bytestr=144102219, vector=144103484, maxdepth=5)
>     at bytecode.c:694
> #21 0x0815d5ee in funcall_lambda (fun=144103676, nargs=0, 
>     arg_vector=0xaffc23e4) at eval.c:3088
> #22 0x0815db09 in Ffuncall (nargs=1, args=0xaffc23e0) at eval.c:2956
> #23 0x0818ab27 in Fbyte_code (bytestr=143864939, vector=143869220, maxdepth=3)
>     at bytecode.c:694
> #24 0x0815d5ee in funcall_lambda (fun=143869436, nargs=1, 
>     arg_vector=0xaffc2574) at eval.c:3088
> #25 0x0815db09 in Ffuncall (nargs=2, args=0xaffc2570) at eval.c:2956
> #26 0x0815a1ec in Fcall_interactively (function=142776193, 
>     record_flag=137558217, keys=137598716) at callint.c:884
> #27 0x080fbb0d in Fcommand_execute (cmd=142776193, record_flag=137558217, 
> ---Type <return> to continue, or q <return> to quit---
>     keys=-514, special=137558217) at keyboard.c:9759
> #28 0x081044b8 in command_loop_1 () at keyboard.c:1791
> #29 0x0815bee2 in internal_condition_case (bfun=0x8104160 <command_loop_1>, 
>     handlers=137602857, hfun=0x80fc610 <cmd_error>) at eval.c:1473
> #30 0x080f699e in command_loop_2 () at keyboard.c:1328
> #31 0x0815bbbc in internal_catch (tag=-514, func=0x80f6970 <command_loop_2>, 
>     arg=137558217) at eval.c:1211
> #32 0x080f677e in command_loop () at keyboard.c:1307
> #33 0x080f6824 in recursive_edit_1 () at keyboard.c:1000
> #34 0x080f6930 in Frecursive_edit () at keyboard.c:1061
> #35 0x080f58be in main (argc=3, argv=0xaffc2e54) at emacs.c:1789
>
> Lisp Backtrace:
> "accept-process-output"
> "imap-wait-for-tag"
> "nnimap-retrieve-groups"
> "gnus-retrieve-groups"
> "gnus-read-active-file-2"
> "gnus-read-active-file-1"
> "gnus-read-active-file"
> "gnus-group-get-new-news"
> "call-interactively"
> (gdb) xba
> "accept-process-output"
> "imap-wait-for-tag"
> "nnimap-retrieve-groups"
> "gnus-retrieve-groups"
> "gnus-read-active-file-2"
> "gnus-read-active-file-1"
> "gnus-read-active-file"
> "gnus-group-get-new-news"
> "call-interactively"
> (gdb) bt full
> #0  0xffffe410 in __kernel_vsyscall ()
> No symbol table info available.
> #1  0xa77f7d2d in select () from /lib/tls/i686/cmov/libc.so.6
> No symbol table info available.
> #2  0x0819228b in wait_reading_process_output (time_limit=0, microsecs=100000, 
>     read_kbd=0, do_display=0, wait_for_cell=137558217, wait_proc=0x8b7ada8, 
>     just_wait_proc=0) at process.c:4494
>         Atemp = {
>   fds_bits = {48, 48, 400, 148630114, 2, 0, 1, 48, 146255272, 400, 0, 
>     148630172, 146255276, 135672289, 48, 48, 135049360, 146328635, 137269152, 
>     -1342432636, -1342432760, 135871880, 146328619, 2, -1342432728, 3, 
>     145778830, -1342432636, -1342432664, 135650297, 146255276, 146328635}
> }
>         Ctemp = {
>   fds_bits = {0 <repeats 25 times>, 268435456, 48, 48, -1342432792, 135869785, 
>     13, 135049360}
> }
>         timeout_reduced_for_timers = 0
>         channel = <value optimized out>
>         nfds = 0
>         Available = {
>   fds_bits = {256, 0 <repeats 31 times>}
> }
> ---Type <return> to continue, or q <return> to quit---
>         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 = 88000
> }
>         end_time = {
>   tv_sec = 1144441079, 
>   tv_usec = 90100
> }
>         wait_channel = 8
>         got_some_input = 0
>         saved_waiting_for_user_input_p = 0
> #3  0x08193f5a in Faccept_process_output (process=146255276, seconds=0, 
>     millisec=100, just_this_one=137558217) at process.c:3893
>         carry = <value optimized out>
>         secs = 0
> ---Type <return> to continue, or q <return> to quit---
>         usecs = -1342432616
> #4  0x0815dc3a in Ffuncall (nargs=4, args=0xaffc1cc0) at eval.c:2911
>         fun = <value optimized out>
>         funcar = <value optimized out>
>         numargs = 3
>         val = <value optimized out>
>         backtrace = {
>   next = 0xaffc1db8, 
>   function = 0xaffc1cc0, 
>   args = 0xaffc1cc4, 
>   nargs = 3, 
>   evalargs = 0 '\0', 
>   debug_on_exit = 0 '\0'
> }
>         internal_args = (Lisp_Object *) 0xaffc1c50
>         i = 0
> #5  0x0818ab27 in Fbyte_code (bytestr=146094019, vector=146096036, maxdepth=8)
>     at bytecode.c:694
>         v1 = 50
>         v2 = <value optimized out>
>         op = <value optimized out>
>         vectorp = (Lisp_Object *) 0x8b53fa8
>         stack = {
> ---Type <return> to continue, or q <return> to quit---
>   pc = 0x8b06a58 "[...]", 
>   top = 0xaffc1ccc, 
>   bottom = 0xaffc1cc0, 
>   byte_string = 146094019, 
>   byte_string_start = 0x8b06a14 "[...]", 
>   constants = 146096036, 
>   next = 0xaffc1e40
> }
>         top = (Lisp_Object *) 0xaffc1cc0
>         result = <value optimized out>
> #6  0x0815d5ee in funcall_lambda (fun=146096252, nargs=2, 
>     arg_vector=0xaffc1df4) at eval.c:3088
>         val = <value optimized out>
>         syms_left = <value optimized out>
>         next = <value optimized out>
>         i = 2
>         optional = 1
>         rest = 0
> #7  0x0815db09 in Ffuncall (nargs=3, args=0xaffc1df0) at eval.c:2956
>         fun = 146096252
>         funcar = <value optimized out>
>         numargs = 2
>         val = <value optimized out>
> ---Type <return> to continue, or q <return> to quit---
>         backtrace = {
>   next = 0xaffc1ee8, 
>   function = 0xaffc1df0, 
>   args = 0xaffc1df4, 
>   nargs = 2, 
>   evalargs = 0 '\0', 
>   debug_on_exit = 0 '\0'
> }
>         internal_args = (Lisp_Object *) 0xaffc1df4
>         i = <value optimized out>
> #8  0x0818ab27 in Fbyte_code (bytestr=146175931, vector=146193772, maxdepth=8)
>     at bytecode.c:694
>         v1 = 245
>         v2 = <value optimized out>
>         op = <value optimized out>
>         vectorp = (Lisp_Object *) 0x8b6bd70
>         stack = {
>   pc = 0x8ae2fe6 "[...]", 
>   top = 0xaffc1df8, 
>   bottom = 0xaffc1df0, 
>   byte_string = 146175931, 
>   byte_string_start = 0x8ae2f54 "[...]", 
> ---Type <return> to continue, or q <return> to quit---
>   constants = 146193772, 
>   next = 0xaffc1f70
> }
>         top = (Lisp_Object *) 0xaffc1df0
>         result = <value optimized out>
> #9  0x0815d5ee in funcall_lambda (fun=146194132, nargs=2, 
>     arg_vector=0xaffc1f24) at eval.c:3088
>         val = <value optimized out>
>         syms_left = <value optimized out>
>         next = <value optimized out>
>         i = 2
>         optional = 1
>         rest = 0
> #10 0x0815db09 in Ffuncall (nargs=3, args=0xaffc1f20) at eval.c:2956
>         fun = 146194132
>         funcar = <value optimized out>
>         numargs = 2
>         val = <value optimized out>
>         backtrace = {
>   next = 0xaffc2018, 
>   function = 0xaffc1f20, 
>   args = 0xaffc1f24, 
>   nargs = 2, 
> ---Type <return> to continue, or q <return> to quit---
>   evalargs = 0 '\0', 
>   debug_on_exit = 0 '\0'
> }
>         internal_args = (Lisp_Object *) 0xaffc1f24
>         i = <value optimized out>
> #11 0x0818ab27 in Fbyte_code (bytestr=142955195, vector=143969076, maxdepth=7)
>     at bytecode.c:694
>         v1 = 176
>         v2 = <value optimized out>
>         op = <value optimized out>
>         vectorp = (Lisp_Object *) 0x894cb38
>         stack = {
>   pc = 0x88f4cca "[...]", 
>   top = 0xaffc1f28, 
>   bottom = 0xaffc1f20, 
>   byte_string = 142955195, 
>   byte_string_start = 0x88f4c10 "[...]", 
>   constants = 143969076, 
>   next = 0xaffc20a0
> }
>         top = (Lisp_Object *) 0xaffc1f20
>         result = <value optimized out>
> #12 0x0815d5ee in funcall_lambda (fun=143969292, nargs=2, 
> ---Type <return> to continue, or q <return> to quit---
>     arg_vector=0xaffc2054) at eval.c:3088
>         val = <value optimized out>
>         syms_left = <value optimized out>
>         next = <value optimized out>
>         i = 2
>         optional = 0
>         rest = 0
> #13 0x0815db09 in Ffuncall (nargs=3, args=0xaffc2050) at eval.c:2956
>         fun = 143969292
>         funcar = <value optimized out>
>         numargs = 2
>         val = <value optimized out>
>         backtrace = {
>   next = 0xaffc2148, 
>   function = 0xaffc2050, 
>   args = 0xaffc2054, 
>   nargs = 2, 
>   evalargs = 0 '\0', 
>   debug_on_exit = 0 '\0'
> }
>         internal_args = (Lisp_Object *) 0xaffc2054
>         i = <value optimized out>
> #14 0x0818ab27 in Fbyte_code (bytestr=144102571, vector=144105388, maxdepth=6)
> ---Type <return> to continue, or q <return> to quit---
>     at bytecode.c:694
>         v1 = 51
>         v2 = <value optimized out>
>         op = <value optimized out>
>         vectorp = (Lisp_Object *) 0x896dfb0
>         stack = {
>   pc = 0x88a65b8 "[...]", 
>   top = 0xaffc2058, 
>   bottom = 0xaffc2050, 
>   byte_string = 144102571, 
>   byte_string_start = 0x88a65a8 "[...]", 
>   constants = 144105388, 
>   next = 0xaffc21d0
> }
>         top = (Lisp_Object *) 0xaffc2050
>         result = <value optimized out>
> #15 0x0815d5ee in funcall_lambda (fun=144105556, nargs=2, 
>     arg_vector=0xaffc2184) at eval.c:3088
>         val = <value optimized out>
>         syms_left = <value optimized out>
>         next = <value optimized out>
>         i = 2
>         optional = 0
> ---Type <return> to continue, or q <return> to quit---
>         rest = 0
> #16 0x0815db09 in Ffuncall (nargs=3, args=0xaffc2180) at eval.c:2956
>         fun = 144105556
>         funcar = <value optimized out>
>         numargs = 2
>         val = <value optimized out>
>         backtrace = {
>   next = 0xaffc2278, 
>   function = 0xaffc2180, 
>   args = 0xaffc2184, 
>   nargs = 2, 
>   evalargs = 0 '\0', 
>   debug_on_exit = 0 '\0'
> }
>         internal_args = (Lisp_Object *) 0xaffc2184
>         i = <value optimized out>
> #17 0x0818ab27 in Fbyte_code (bytestr=144102315, vector=144103916, maxdepth=6)
>     at bytecode.c:694
>         v1 = 461
>         v2 = <value optimized out>
>         op = <value optimized out>
>         vectorp = (Lisp_Object *) 0x896d9f0
>         stack = {
> ---Type <return> to continue, or q <return> to quit---
>   pc = 0x88a6452 "[...]", 
>   top = 0xaffc2188, 
>   bottom = 0xaffc2180, 
>   byte_string = 144102315, 
>   byte_string_start = 0x88a6280 "[...]", 
>   constants = 144103916, 
>   next = 0xaffc2300
> }
>         top = (Lisp_Object *) 0xaffc2180
>         result = <value optimized out>
> #18 0x0815d5ee in funcall_lambda (fun=144104276, nargs=2, 
>     arg_vector=0xaffc22b4) at eval.c:3088
>         val = <value optimized out>
>         syms_left = <value optimized out>
>         next = <value optimized out>
>         i = 2
>         optional = 0
>         rest = 0
> #19 0x0815db09 in Ffuncall (nargs=3, args=0xaffc22b0) at eval.c:2956
>         fun = 144104276
>         funcar = <value optimized out>
> ---Type <return> to continue, or q <return> to quit---
>         numargs = 2
>         val = <value optimized out>
>         backtrace = {
>   next = 0xaffc23a8, 
>   function = 0xaffc22b0, 
>   args = 0xaffc22b4, 
>   nargs = 2, 
>   evalargs = 0 '\0', 
>   debug_on_exit = 0 '\0'
> }
>         internal_args = (Lisp_Object *) 0xaffc22b4
>         i = <value optimized out>
> #20 0x0818ab27 in Fbyte_code (bytestr=144102219, vector=144103484, maxdepth=5)
>     at bytecode.c:694
>         v1 = 68
>         v2 = <value optimized out>
>         op = <value optimized out>
>         vectorp = (Lisp_Object *) 0x896d840
>         stack = {
>   pc = 0x88a61c9 "[...]", 
>   top = 0xaffc22b8, 
>   bottom = 0xaffc22b0, 
>   byte_string = 144102219, 
> ---Type <return> to continue, or q <return> to quit---
>   byte_string_start = 0x88a6180 "[...]", 
>   constants = 144103484, 
>   next = 0xaffc2420
> }
>         top = (Lisp_Object *) 0xaffc22b0
>         result = <value optimized out>
> #21 0x0815d5ee in funcall_lambda (fun=144103676, nargs=0, 
>     arg_vector=0xaffc23e4) at eval.c:3088
>         val = <value optimized out>
>         syms_left = <value optimized out>
>         next = <value optimized out>
>         i = 0
>         optional = 1
>         rest = 0
> #22 0x0815db09 in Ffuncall (nargs=1, args=0xaffc23e0) at eval.c:2956
>         fun = 144103676
>         funcar = <value optimized out>
>         numargs = 0
>         val = <value optimized out>
>         backtrace = {
>   next = 0xaffc24c8, 
>   function = 0xaffc23e0, 
>   args = 0xaffc23e4, 
> ---Type <return> to continue, or q <return> to quit---
>   nargs = 0, 
>   evalargs = 0 '\0', 
>   debug_on_exit = 0 '\0'
> }
>         internal_args = (Lisp_Object *) 0xaffc23e4
>         i = <value optimized out>
> #23 0x0818ab27 in Fbyte_code (bytestr=143864939, vector=143869220, maxdepth=3)
>     at bytecode.c:694
>         v1 = 101
>         v2 = <value optimized out>
>         op = <value optimized out>
>         vectorp = (Lisp_Object *) 0x8934528
>         stack = {
>   pc = 0x89ba169 "[...]", 
>   top = 0xaffc23e0, 
>   bottom = 0xaffc23e0, 
>   byte_string = 143864939, 
>   byte_string_start = 0x89ba10c "[...]", 
>   constants = 143869220, 
>   next = 0x0
> }
>         top = (Lisp_Object *) 0xaffc23e0
> ---Type <return> to continue, or q <return> to quit---
>         result = <value optimized out>
> #24 0x0815d5ee in funcall_lambda (fun=143869436, nargs=1, 
>     arg_vector=0xaffc2574) at eval.c:3088
>         val = <value optimized out>
>         syms_left = <value optimized out>
>         next = <value optimized out>
>         i = 1
>         optional = 1
>         rest = 0
> #25 0x0815db09 in Ffuncall (nargs=2, args=0xaffc2570) at eval.c:2956
>         fun = 143869436
>         funcar = <value optimized out>
>         numargs = 1
>         val = <value optimized out>
>         backtrace = {
>   next = 0xaffc2718, 
>   function = 0xaffc2570, 
>   args = 0xaffc2574, 
>   nargs = 1, 
>   evalargs = 0 '\0', 
>   debug_on_exit = 0 '\0'
> }
>         internal_args = (Lisp_Object *) 0xaffc2574
> ---Type <return> to continue, or q <return> to quit---
>         i = <value optimized out>
> #26 0x0815a1ec in Fcall_interactively (function=142776193, 
>     record_flag=137558217, keys=137598716) at callint.c:884
>         val = <value optimized out>
>         fun = <value optimized out>
>         specs = 143864955
>         teml = <value optimized out>
>         up_event = 137558217
>         enable = 137558217
>         next_event = 0
>         prefix_arg = 137558217
>         string = <value optimized out>
>         tem = (unsigned char *) 0x81b8871 ""
>         i = <value optimized out>
>         j = 1
>         foo = <value optimized out>
>         prompt1 = '\0' <repeats 99 times>
>         arg_from_tty = 0
>         key_count = 1
>         record_then_fail = 0
>         save_this_command = 142776193
>         save_last_command = 143673529
>         save_this_original_command = 142776193
> ---Type <return> to continue, or q <return> to quit---
>         save_real_this_command = 142776193
> #27 0x080fbb0d in Fcommand_execute (cmd=142776193, record_flag=137558217, 
>     keys=-514, special=137558217) at keyboard.c:9759
>         final = 143869436
>         tem = <value optimized out>
>         prefixarg = 137558217
>         backtrace = {
>   next = 0x0, 
>   function = 0x8322670, 
>   args = 0xaffc2740, 
>   nargs = 1, 
>   evalargs = 0 '\0', 
>   debug_on_exit = 0 '\0'
> }
> #28 0x081044b8 in command_loop_1 () at keyboard.c:1791
>         cmd = <value optimized out>
>         lose = <value optimized out>
>         nonundocount = 0
>         keybuf = {824, 848, -1483884048, -1342429284, -1476678818, 134536200, 
>   -1483884036, -1476636684, 9287600, -1483883960, -1342429196, -1476698759, 
>   -1485575509, 134537900, 0, 0, 134526604, 110932256, 134537597, 0, 
>   -1342429224, -1342429376, 0, -1485635584, 137558217, 139268593, 0, 1, 1, 
>   -1342429192}
> ---Type <return> to continue, or q <return> to quit---
>         i = 1
>         prev_modiff = 1176
>         prev_buffer = (struct buffer *) 0x8867238
>         was_locked = 0
>         already_adjusted = <value optimized out>
> #29 0x0815bee2 in internal_condition_case (bfun=0x8104160 <command_loop_1>, 
>     handlers=137602857, hfun=0x80fc610 <cmd_error>) at eval.c:1473
>         val = <value optimized out>
>         c = {
>   tag = 137558217, 
>   val = 137558217, 
>   next = 0xaffc2920, 
>   gcpro = 0x0, 
>   jmp = {{
>       __jmpbuf = {0, 1, 1, -1342428952, -1342429184, 135642787}, 
>       __mask_was_saved = 0, 
>       __saved_mask = {
>         __val = {0, 2952538336, 2818331912, 134537597, 110932256, 16777216, 
>           0 <repeats 21 times>, 2809367228, 2811083336, 2818330612, 
>           2818331912, 1}
>       }
>     }}, 
>   backlist = 0x0, 
> ---Type <return> to continue, or q <return> to quit---
>   handlerlist = 0x0, 
>   lisp_eval_depth = 0, 
>   pdlcount = 2, 
>   poll_suppress_count = 1, 
>   interrupt_input_blocked = 0, 
>   byte_stack = 0x0
> }
>         h = {
>   handler = 137602857, 
>   var = 137558217, 
>   chosen_clause = 136030732, 
>   tag = 0xaffc280c, 
>   next = 0x0
> }
> #30 0x080f699e in command_loop_2 () at keyboard.c:1328
>         val = <value optimized out>
> #31 0x0815bbbc in internal_catch (tag=-514, func=0x80f6970 <command_loop_2>, 
>     arg=137558217) at eval.c:1211
>         c = {
>   tag = 137599089, 
>   val = 137558217, 
>   next = 0x0, 
>   gcpro = 0x0, 
> ---Type <return> to continue, or q <return> to quit---
>   jmp = {{
>       __jmpbuf = {0, 1, 1, -1342428696, -1342428912, 135642031}, 
>       __mask_was_saved = 0, 
>       __saved_mask = {
>         __val = {0, 0, 139993024, 12, 12, 2952538152, 135555972, 139993024, 
>           12, 12, 12, 2952538436, 137743378, 137740448, 137740449, 2952538568, 
>           135575905, 137740449, 137743378, 137558217, 137590072, 1, 137590072, 
>           137558217, 137558241, 2, 137743376, 2952538584, 137740448, 
>           137740449, 0, 2952538632}
>       }
>     }}, 
>   backlist = 0x0, 
>   handlerlist = 0x0, 
>   lisp_eval_depth = 0, 
>   pdlcount = 2, 
>   poll_suppress_count = 1, 
>   interrupt_input_blocked = 0, 
>   byte_stack = 0x0
> }
> #32 0x080f677e in command_loop () at keyboard.c:1307
> No locals.
> #33 0x080f6824 in recursive_edit_1 () at keyboard.c:1000
>         val = <value optimized out>
> ---Type <return> to continue, or q <return> to quit---
> #34 0x080f6930 in Frecursive_edit () at keyboard.c:1061
>         buffer = <value optimized out>
> #35 0x080f58be in main (argc=3, argv=0xaffc2e54) at emacs.c:1789
>         tz = 0x0
>         dummy = -1342427688
>         stack_bottom_variable = 8 '\b'
>         do_initial_setlocale = 1
>         skip_args = 0
>         rlim = {
>   rlim_cur = 8388608, 
>   rlim_max = 18446744073709551615
> }
>         no_loadup = 0
>         junk = 0x0
>
> Lisp Backtrace:
> "accept-process-output"
> "imap-wait-for-tag"
> "nnimap-retrieve-groups"
> "gnus-retrieve-groups"
> "gnus-read-active-file-2"
> "gnus-read-active-file-1"
> "gnus-read-active-file"
> ---Type <return> to continue, or q <return> to quit---
> "gnus-group-get-new-news"
> "call-interactively"

-- 
Leon

Re: gnus makes emacs lose response

[Ralf Angeli]

* Ralf Angeli (2006-04-07) writes:

> * Kim F. Storm (2006-04-06) writes:
>
>> then examine the stack and other stuff to see
>> where it hangs, e.g. as a first step, send us
>> the output from these commands:
[...]
> (gdb) bt
> #0  0xffffe410 in __kernel_vsyscall ()
> #1  0xa77f7d2d in select () from /lib/tls/i686/cmov/libc.so.6
> #2  0x0819228b in wait_reading_process_output (time_limit=0, microsecs=100000, 
>     read_kbd=0, do_display=0, wait_for_cell=137558217, wait_proc=0x8b7ada8, 
>     just_wait_proc=0) at process.c:4494
> #3  0x08193f5a in Faccept_process_output (process=146255276, seconds=0, 
>     millisec=100, just_this_one=137558217) at process.c:3893
[...]
> Lisp Backtrace:
> "accept-process-output"
> "imap-wait-for-tag"
> "nnimap-retrieve-groups"
> "gnus-retrieve-groups"

Is there anything else I can do to help debugging this?

I don't have the original report, so I don't know under which
circumstances the hang happens there.  In my case it happens if I
connect to the internet via modem, open an encrypted connection to an
IMAP server, cut the internet connection, connect to the internet
again, and try to connect to the IMAP server again.  I am not sure if
this is a problem of Emacs, the programs used for opening the
connection to the server, or the kernel.  I tried it now with openssl
s_client, starttls, and gnutls-cli.  All three behave identically on
GNU/Linux, i.e. the hang happens with all of them.

BTW, in contrast to Emacs on GNU/Linux, the Windows port of Emacs does
not hang.  Perhaps this information helps identifying the cause.

-- 
Ralf

Re: gnus makes emacs lose response

[Leon]

Ralf Angeli <angeli@iwi.uni-sb.de> writes:

> * Ralf Angeli (2006-04-07) writes:
>
>> * Kim F. Storm (2006-04-06) writes:
>>
>>> then examine the stack and other stuff to see
>>> where it hangs, e.g. as a first step, send us
>>> the output from these commands:
> [...]
>> (gdb) bt
>> #0  0xffffe410 in __kernel_vsyscall ()
>> #1  0xa77f7d2d in select () from /lib/tls/i686/cmov/libc.so.6
>> #2  0x0819228b in wait_reading_process_output (time_limit=0, microsecs=100000, 
>>     read_kbd=0, do_display=0, wait_for_cell=137558217, wait_proc=0x8b7ada8, 
>>     just_wait_proc=0) at process.c:4494
>> #3  0x08193f5a in Faccept_process_output (process=146255276, seconds=0, 
>>     millisec=100, just_this_one=137558217) at process.c:3893
> [...]
>> Lisp Backtrace:
>> "accept-process-output"
>> "imap-wait-for-tag"
>> "nnimap-retrieve-groups"
>> "gnus-retrieve-groups"
>
> Is there anything else I can do to help debugging this?
>
> I don't have the original report, so I don't know under which
> circumstances the hang happens there.  In my case it happens if I
> connect to the internet via modem, open an encrypted connection to an
> IMAP server, cut the internet connection, connect to the internet
> again, and try to connect to the IMAP server again.  I am not sure if
> this is a problem of Emacs, the programs used for opening the
> connection to the server, or the kernel.  I tried it now with openssl
> s_client, starttls, and gnutls-cli.  All three behave identically on
> GNU/Linux, i.e. the hang happens with all of them.
>
> BTW, in contrast to Emacs on GNU/Linux, the Windows port of Emacs does
> not hang.  Perhaps this information helps identifying the cause.

Hi Ralf,

Here are steps to reproduce the bug.

1. Add the following lines to ~/.gnus.el
    (gnus-demon-add-handler 'gnus-group-get-new-news 2 t)
    (gnus-demon-init)
2. fire up gnus
3. cut the network

Then when demon tries to get new News, emacs hangs. What's outrageous is
Ctrl-g won't be able to stop the process.

If you put the network back on, emacs will come to life again.

Regards,
-- 
Leon
Emacs: GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.8.17) of
2006-04-18

Re: gnus makes emacs lose response

[Ralf Angeli]

* Leon (2006-04-18) writes:

> Here are steps to reproduce the bug.
>
> 1. Add the following lines to ~/.gnus.el
>     (gnus-demon-add-handler 'gnus-group-get-new-news 2 t)
>     (gnus-demon-init)
> 2. fire up gnus
> 3. cut the network
>
> Then when demon tries to get new News, emacs hangs. What's outrageous is
> Ctrl-g won't be able to stop the process.
>
> If you put the network back on, emacs will come to life again.

Hm, I cannot reproduce this problem when I shut down a PPP connection.
Maybe this only happens if the interface is still available.

-- 
Ralf

Re: gnus makes emacs lose response

[Leon]

Ralf Angeli <angeli@iwi.uni-sb.de> writes:

> * Leon (2006-04-18) writes:
>
>> Here are steps to reproduce the bug.
>>
>> 1. Add the following lines to ~/.gnus.el
>>     (gnus-demon-add-handler 'gnus-group-get-new-news 2 t)
>>     (gnus-demon-init)
>> 2. fire up gnus
>> 3. cut the network
>>
>> Then when demon tries to get new News, emacs hangs. What's outrageous is
>> Ctrl-g won't be able to stop the process.
>>
>> If you put the network back on, emacs will come to life again.
>
> Hm, I cannot reproduce this problem when I shut down a PPP connection.
> Maybe this only happens if the interface is still available.

Hi Ralf,

I'm using static ip in a college LAN. I cut the network by
`/etc/init.d/network stop'. I can reproduce this bug 100% sure.

Is it necessary for me to submit a backtrace? I used to do the install
with `make install INSTALL_STRIP="-s"'. Is this the reason my
backtrace didn't contain debug info?

Thank you for your effort in fixing this bug.
-- 
Leon

Re: gnus makes emacs lose response

[Ralf Angeli]

* Ralf Angeli (2006-04-17) writes:

>> Lisp Backtrace:
>> "accept-process-output"
>> "imap-wait-for-tag"
>> "nnimap-retrieve-groups"
>> "gnus-retrieve-groups"
>
> Is there anything else I can do to help debugging this?
>
> I don't have the original report, so I don't know under which
> circumstances the hang happens there.  In my case it happens if I
> connect to the internet via modem, open an encrypted connection to an
> IMAP server, cut the internet connection, connect to the internet
> again, and try to connect to the IMAP server again.  I am not sure if
> this is a problem of Emacs, the programs used for opening the
> connection to the server, or the kernel.  I tried it now with openssl
> s_client, starttls, and gnutls-cli.  All three behave identically on
> GNU/Linux, i.e. the hang happens with all of them.
>
> BTW, in contrast to Emacs on GNU/Linux, the Windows port of Emacs does
> not hang.  Perhaps this information helps identifying the cause.

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 am not sure what the right course of action on GNU/Linux would be to
remedy the problem.  Should programs like openssl die when the
internet connection is being closed?  Or renegotiate a connection?
Should Emacs kill the respective processes if there is no answer after
a certain amount of time and start new ones?  I guess the latter
suggestion is not sensible because Emacs does not know why there is no
answer.  It could as well be that the server is down.

For now, I think, I can work around this problem by writing a script
which closes the internet connection as well as kills all openssl (and
similar) processes.

-- 
Ralf

Re: gnus makes emacs lose response

[Stefan Monnier]

>>> Lisp Backtrace:
>>> "accept-process-output"
>>> "imap-wait-for-tag"
>>> "nnimap-retrieve-groups"
>>> "gnus-retrieve-groups"
>> 
>> Is there anything else I can do to help debugging this?
[...]
> 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.
[...]
> I am not sure what the right course of action on GNU/Linux would be to
> remedy the problem.  Should programs like openssl die when the
> internet connection is being closed?  Or renegotiate a connection?

Note that even if openssl doesn't die and hangs, it shouldn't cause Emacs
to freeze.  I.e. it is important to make sure that C-g works.


        Stefan

Re: gnus makes emacs lose response

[Ralf Angeli]

* Stefan Monnier (2006-04-19) writes:

> Note that even if openssl doesn't die and hangs, it shouldn't cause Emacs
> to freeze.  I.e. it is important to make sure that C-g works.

In my case `C-g' works.  Sorry for not making this clear beforehand.
It's Leon's test case where `C-g' fails.  I just thought they might be
related because the backtraces looked somewhat similar.  Unfortunately
I cannot reproduce Leon's problem at the moment for getting a
backtrace with debug information.

-- 
Ralf

Re: gnus makes emacs lose response

[Gregory Novak]

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.

Greg

Re: gnus makes emacs lose response

[Kim F. Storm]

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

Re: gnus makes emacs lose response

[Kim F. Storm]

Ralf Angeli <angeli@iwi.uni-sb.de> writes:

> * Ralf Angeli (2006-04-17) writes:
>
>>> Lisp Backtrace:
>>> "accept-process-output"
>>> "imap-wait-for-tag"
>>> "nnimap-retrieve-groups"
>>> "gnus-retrieve-groups"
>>
>> BTW, in contrast to Emacs on GNU/Linux, the Windows port of Emacs does
>> not hang.  Perhaps this information helps identifying the cause.
>
> 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.

But Emacs should still respond to C-g in this case ... or?


> I am not sure what the right course of action on GNU/Linux would be to
> remedy the problem.  Should programs like openssl die when the
> internet connection is being closed?  Or renegotiate a connection?
> Should Emacs kill the respective processes if there is no answer after
> a certain amount of time and start new ones?  I guess the latter
> suggestion is not sensible because Emacs does not know why there is no
> answer.  It could as well be that the server is down.

Emacs cannot do that in general -- but Gnus may know when it makes
sense to kill the process and start a new one....

I see similar problems connection to one of the news servers at my ISP.
I just interrupt Gnus, and make anoter refresh -- I guess Gnus could
just as well do this automatically if there is no response from the
server it used last time. 

> For now, I think, I can work around this problem by writing a script
> which closes the internet connection as well as kills all openssl (and
> similar) processes.

Could you write something for PROBLEMS on the matter?

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

Re: gnus makes emacs lose response

[Richard Stallman]

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

    But Emacs should still respond to C-g in this case ... or?

Yes--if C-g fails to work, it is a bug.

So we need to determine WHY it fails to work.
Perhaps wait_reading_process_output, when called on behalf
of accept-process-output, fails to take note of quit-flag.

Can someone please investigate whether that is true?

    > I am not sure what the right course of action on GNU/Linux would be to
    > remedy the problem.  Should programs like openssl die when the
    > internet connection is being closed?  Or renegotiate a connection?

I don't know whether openssl can keep working when a phone connection
drops and is reestablished, but I have seen scp connections keep
working when I removed and then reinserted a Wifi card.  These cases
are not the same but they are analogous; if the openssl/phone case
does not work now, it ought to work.

    I see similar problems connection to one of the news servers at my ISP.
    I just interrupt Gnus, and make anoter refresh -- I guess Gnus could
    just as well do this automatically if there is no response from the
    server it used last time. 

I don't entirely understand that proposal.  Does it aim to work around
the failure of C-g?  Does it aim to DTRT without need to type C-g?
If openssl could resume its connection when you reconnect the phone line,
would that make this proposal unnecessary?  Would that make this proposal
undesirable or incorrect?

Re: gnus makes emacs lose response

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     I see similar problems connection to one of the news servers at my ISP.
>     I just interrupt Gnus, and make anoter refresh -- I guess Gnus could
>     just as well do this automatically if there is no response from the
>     server it used last time. 
>
> I don't entirely understand that proposal.  Does it aim to work around
> the failure of C-g?  Does it aim to DTRT without need to type C-g?
> If openssl could resume its connection when you reconnect the phone line,
> would that make this proposal unnecessary?  Would that make this proposal
> undesirable or incorrect?

The proposal is simply that Gnus should detect a stale connection to
an NNTP server -- if the server doesn't respond in a timely manner, it
should drop the connection and open a new one.  

As it is now, when I ask Gnus to look for new news, it sometimes
"hang" for a long time waiting for the news server to respond -- since
I'm impatient, I interrupt this with C-g (it works!) which seems to
cause Gnus to close the connection. Then I simply repeat the "get new
news" command manually.  I think Gnus could do this automatically for me!

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

Re: gnus makes emacs lose response

[Richard Stallman]

    The proposal is simply that Gnus should detect a stale connection to
    an NNTP server -- if the server doesn't respond in a timely manner, it
    should drop the connection and open a new one.  

It depends on the precise definition of "stale".  If it would include
a connection made via WiFi when the card has been pulled out, then it
would create a bug.

Re: gnus makes emacs lose response

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     The proposal is simply that Gnus should detect a stale connection to
>     an NNTP server -- if the server doesn't respond in a timely manner, it
>     should drop the connection and open a new one.  
>
> It depends on the precise definition of "stale".  If it would include
> a connection made via WiFi when the card has been pulled out, then it
> would create a bug.

I don't follow.

I'm talking about Gnus detecting that the TCP connection to the NNTP
server is "stale" by putting a timeout on the response.  
I.e. I don't know about an underlying "physical" WiFi or PPP connection.

You say that Emacs _must_ hang until you decide to put the WiFi card
back in or you hit C-g to completely terminate the fetching of new
articles and messages (from any server)?

Why can't Gnus decide that "hey I've waited 15 seconds for a response,
so let's stop this nonsense and try again"?  And if the second attempt
fails as well, conclude that that particular Mail or NNTP server is not
reachable at this time and go on to other business?

In my setup, I don't use openssl or any such fancy stuff -- which may
be why I'm able to interrupt the "stale connection" with C-g.

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

Re: gnus makes emacs lose response

[Richard Stallman]

    You say that Emacs _must_ hang until you decide to put the WiFi card
    back in or you hit C-g to completely terminate the fetching of new
    articles and messages (from any server)?

Yes, I think so.  It would be a screw if it canceled a long operation
and made me start from the beginning, just because I did not remove
and reinsert the card fast enough to beat the timeout.  What if it took
me 20 seconds to notice that the wireless connection was no longer actually
transferring any data?  That has happened.

    Why can't Gnus decide that "hey I've waited 15 seconds for a response,
    so let's stop this nonsense and try again"?

To cancel the operation and try again from the beginning is ok,
provided that the operation is always fast when it does work.

Basically, what I don't want it to do is this: you have been
transferring for 20 minutes, and then there's a problem, and it starts
over, and you have to redo that first 20 minutes' worth.

Re: gnus makes emacs lose response

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> Basically, what I don't want it to do is this: you have been
> transferring for 20 minutes, and then there's a problem, and it starts
> over, and you have to redo that first 20 minutes' worth.

I guess I'm spoiled by having had fast Internet access for years.

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

Re: gnus makes emacs lose response

[Jason Rumney]

Richard Stallman wrote:
>     The proposal is simply that Gnus should detect a stale connection to
>     an NNTP server -- if the server doesn't respond in a timely manner, it
>     should drop the connection and open a new one.  
>
> It depends on the precise definition of "stale".  If it would include
> a connection made via WiFi when the card has been pulled out, then it
> would create a bug.
>   
I don't see how creating a new connection, which will either fail or go 
via another route in the above case, could be considered a bug.

Re: gnus makes emacs lose response

[Stefan Monnier]

> Yes--if C-g fails to work, it is a bug.

> So we need to determine WHY it fails to work.
> Perhaps wait_reading_process_output, when called on behalf
> of accept-process-output, fails to take note of quit-flag.

I use the patch below to catch such problems.


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

Re: gnus makes emacs lose response

[Bob Rogers]

   From: Richard Stallman <rms@gnu.org>
   Date: Wed, 23 Aug 2006 10:45:30 -0400

       > 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 am not sure what the right course of action on GNU/Linux would be to
       > remedy the problem.  Should programs like openssl die when the
       > internet connection is being closed?  Or renegotiate a connection?

   I don't know whether openssl can keep working when a phone connection
   drops and is reestablished, but I have seen scp connections keep
   working when I removed and then reinserted a Wifi card.  These cases
   are not the same but they are analogous; if the openssl/phone case
   does not work now, it ought to work.

The problem is fundamental to dialups (and my apologies if this is old
hat, and by "it ought to work" you really meant "Gnus" and not
"openssl").

    For a wireless card or cable modem, the DHCP server remembers your
hardware address, which it uses to give you the IP address you had
before, so established TCP connections resume working as soon as the
interface comes back up.  When you redial, the computer attached to the
modem bank has no clue who are (and might even be a different computer
than before), so you usually get a different IP address, making TCP
connections established with the old IP address unusable.  Either way,
OpenSSL probably isn't even aware of all this commotion in the lower
layers of the networking stack.

   So you might consider this a bug in GNU/Linux that it doesn't close
open connections for old addresses.  However, it may not be possible to
decide that an old address is truly and forevermore gone, and so (I am
guessing) they figured that it is more robust to let higher-level
connection timeout mechanisms come into play.  (It may even be specified
that way, but I don't know the relevant RFCs to check.)  By that
interpretation, the observed difference in behavior is really a Windows
bug.  (And it wouldn't be the first time MS chose user convenience over
robustness, now, would it?  ;-)

       I see similar problems connection to one of the news servers at my ISP.
       I just interrupt Gnus, and make anoter refresh -- I guess Gnus could
       just as well do this automatically if there is no response from the
       server it used last time.

   I don't entirely understand that proposal . . .
   If openssl could resume its connection when you reconnect the phone line,
   would that make this proposal unnecessary?  Would that make this proposal
   undesirable or incorrect?

Would it be possible for Gnus to request a timeout when invoking
openssl?  I'm afraid I don't know enough about either to make a more
detailed suggestion, let alone whether this approach could work.  (And
http://www.openssl.org/docs/apps/s_client.html doesn't show any
timeout-related option, which is not hopeful.)

   If not, then restarting the connection after a suitable timeout is
probably the best available technology.

					-- Bob Rogers
					   [who sometimes pretends to be
					   a network engineer, often
					   with success.]
					   http://rgrjr.dyndns.org/

Re: gnus makes emacs lose response

[Kim F. Storm]

Bob Rogers <rogers-emacs@rgrjr.dyndns.org> writes:

> Would it be possible for Gnus to request a timeout when invoking
> openssl?  I'm afraid I don't know enough about either to make a more
> detailed suggestion, let alone whether this approach could work.  (And
> http://www.openssl.org/docs/apps/s_client.html doesn't show any
> timeout-related option, which is not hopeful.)


>    If not, then restarting the connection after a suitable timeout is
> probably the best available technology.

That's what I suggested Gnus should do, i.e.

Start a timer when it tries to open/use the connection.
If connection is opened/response is received, cancel the timer.
If timer runs out, close the connection and try again.


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

Re: gnus makes emacs lose response

[Bob Rogers]

   From: storm@cua.dk (Kim F. Storm)
   Date: Thu, 24 Aug 2006 09:51:49 +0200

   Bob Rogers <rogers-emacs@rgrjr.dyndns.org> writes:

   >    If not, then restarting the connection after a suitable timeout is
   > probably the best available technology.

   That's what I suggested Gnus should do . . .

I assumed readers would know that I was seconding your original
suggestion.  My apologies if this was not clear.

					-- Bob

Re: gnus makes emacs lose response

[Richard Stallman]

    Start a timer when it tries to open/use the connection.
    If connection is opened/response is received, cancel the timer.
    If timer runs out, close the connection and try again.

If Gnus operations that use the connection always involve small
amounts of data, so that restarting one is never a big loss,
then it is ok to implement this strategy.

By contrast, restarting scp every time a connection drops would be a
real disaster with Wifi (compared with resuming the transfer where it
left off).

If one of these Gnus operations can take a long time, then it is like
the scp case, and we must not make Gnus automatically kill it and
restart!

Re: gnus makes emacs lose response

[Richard Stallman]

      When you redial, the computer attached to the
    modem bank has no clue who are (and might even be a different computer
    than before), so you usually get a different IP address, making TCP
    connections established with the old IP address unusable.  Either way,
    OpenSSL probably isn't even aware of all this commotion in the lower
    layers of the networking stack.

That being so, if you're using WiFi then OpenSSL should not die when
the connection drops, but if you're using PPP, then OpenSSL should
die when the connection drops.

Emacs is the wrong place to make the decision.  Emacs is not in a
position to know whether the connection was by phone or by wireless.
If Gnus could impose a timeout, it would fix the problem for phone
connections and cause a spurious problem for wireless.

How can we make the right thing happen in both cases?  Some part of
the system has to be responsible for making the right thing happen in
each of these cases.  Somehow OpenSSL needs to be able to determine
that a low-level connection is irrevocably broken, so it can die.
This may require changes in Linux and GNU Libc as well as OpenSSL,
but I don't know.

We need to report this to the people who can fix it right.

In the mean time, the solution for Emacs is to make sure C-g works.