emacs gets stuck in wait_reading_process_output sometimes

emacs gets stuck in wait_reading_process_output sometimes

[joakim]

#0  0x00110422 in __kernel_vsyscall ()
#1  0x00cb85bd in ___newselect_nocancel () from /lib/libc.so.6
#2  0x081adc25 in select_wrapper (n=-514, rfd=0x0, wfd=0xbfd5a178, xfd=0x0, tmo=0xbfd5a2a8) at process.c:4204
#3  0x081b0e3f in wait_reading_process_output (time_limit=0, microsecs=10000, read_kbd=0, do_display=0, wait_for_cell=137764129, wait_proc=0xb819ca0, just_wait_proc=0) at process.c:4587
#4  0x081b2de7 in Faccept_process_output (process=193043620, seconds=0, millisec=80, just_this_one=137764129) at process.c:3946

This only happens sometimes.

I have a small elisp wrapper for fetchmail, and I think the stuckness
might happen when fetchmail exits, but I'm not sure.

Any hints how to debug this better when it happens?


;jvfetchmail.el
;
;jvfetchmail calls fetchmail. After fetchmail is run, gnus is updated.
;
;my particular mail setup looks like this:
; - get mail via imap with fetchmail
; - filter mail with sieve, using dovecot local delivery agent
; - read mail using gnus from a local dovecot imapd instance on my laptop
;this looks complicated but is surprisingly efficient
;
;jvfetchmail also tries to help you not to obsess over email.
;
;jvfetchmail was only tested on emacs 23

;joakim@verona.se
;call fetchmail and stuff


(defvar jvfetchmail-last-called nil
  "when jvfetvhmail was last called")

(defvar jvfetchmail-in-progress nil)

;TODO process might fail, reset "in-progress" flag
;TODO gnus might fail at end, reset "in-progress" flag
;TODO some way of resetting the flag
(provide 'jvfetchmail)
(defun jvfetchmail-sentinel (process event)
  (setq jvfetchmail-in-progress nil) ;should rather be called lat but currently gnus might fail
  (let*
      ((msg (format "fetchmail %s"  event)))
    (save-excursion
      (set-buffer (get-buffer-create "*fetchmail*"))
      
      (gnus-group-get-new-news)
      (insert msg))
    (princ msg)))
                                        ;if no mail : exited abnormally with code 1
                                        ;otherwise: finished

(defun jvfetchmail ()
  "run fetchmail and stuff"
  (interactive)
  (if jvfetchmail-in-progress
      (message "jvfetchmail is running already, dont be obsessive")
    (progn
      (if jvfetchmail-last-called
          (progn
            (message "jvfetchmail last called %s, %s minutes ago"
                     (format-time-string "%H:%M" jvfetchmail-last-called) 
                     (round (/ (float-time (time-subtract (current-time) jvfetchmail-last-called)) 60))))
        (message "jvfetchmail 1st run this session"))
      (setq jvfetchmail-last-called (current-time))
      (setq jvfetchmail-in-progress t)
      (save-excursion
    
        (set-buffer (get-buffer-create "*jvfetchmail*"))
        (erase-buffer )
        (let*
            ((fetchmail-process (start-process "fetchmail" "*jvfetchmail*" "fetchmail")))
          (set-process-sentinel fetchmail-process 'jvfetchmail-sentinel)
          )
        )
      )
    ))
  
(global-set-key (kbd "<f9> m") 'jvfetchmail)

-- 
Joakim Verona

Re: emacs gets stuck in wait_reading_process_output sometimes

[David Kastrup]

joakim@verona.se writes:

> #0  0x00110422 in __kernel_vsyscall ()
> #1  0x00cb85bd in ___newselect_nocancel () from /lib/libc.so.6
> #2  0x081adc25 in select_wrapper (n=-514, rfd=0x0, wfd=0xbfd5a178, xfd=0x0, tmo=0xbfd5a2a8) at process.c:4204
> #3  0x081b0e3f in wait_reading_process_output (time_limit=0, microsecs=10000, read_kbd=0, do_display=0, wait_for_cell=137764129, wait_proc=0xb819ca0, just_wait_proc=0) at process.c:4587
> #4  0x081b2de7 in Faccept_process_output (process=193043620, seconds=0, millisec=80, just_this_one=137764129) at process.c:3946
>
> This only happens sometimes.
>
> I have a small elisp wrapper for fetchmail, and I think the stuckness
> might happen when fetchmail exits, but I'm not sure.
>
> Any hints how to debug this better when it happens?

Can you check whether it is related to the setting of
process-adaptive-read-buffering?  I seem to remember that tramp
explicitly disabled it to get rid of large inexplicable delays, so it is
not unlikely that there is still some bug lurking in there.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacs gets stuck in wait_reading_process_output sometimes

[joakim]

David Kastrup <dak@gnu.org> writes:

> joakim@verona.se writes:
>
>> #0  0x00110422 in __kernel_vsyscall ()
>> #1  0x00cb85bd in ___newselect_nocancel () from /lib/libc.so.6
>> #2  0x081adc25 in select_wrapper (n=-514, rfd=0x0, wfd=0xbfd5a178, xfd=0x0, tmo=0xbfd5a2a8) at process.c:4204
>> #3  0x081b0e3f in wait_reading_process_output (time_limit=0, microsecs=10000, read_kbd=0, do_display=0, wait_for_cell=137764129, wait_proc=0xb819ca0, just_wait_proc=0) at process.c:4587
>> #4  0x081b2de7 in Faccept_process_output (process=193043620, seconds=0, millisec=80, just_this_one=137764129) at process.c:3946
>>
>> This only happens sometimes.
>>
>> I have a small elisp wrapper for fetchmail, and I think the stuckness
>> might happen when fetchmail exits, but I'm not sure.
>>
>> Any hints how to debug this better when it happens?
>
> Can you check whether it is related to the setting of
> process-adaptive-read-buffering?  I seem to remember that tramp
> explicitly disabled it to get rid of large inexplicable delays, so it is
> not unlikely that there is still some bug lurking in there.

Thanks, I will take a look next time it happens.
-- 
Joakim Verona

Re: emacs gets stuck in wait_reading_process_output sometimes

[David Kastrup]

joakim@verona.se writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Can you check whether it is related to the setting of
>> process-adaptive-read-buffering?  I seem to remember that tramp
>> explicitly disabled it to get rid of large inexplicable delays, so it is
>> not unlikely that there is still some bug lurking in there.
>
> Thanks, I will take a look next time it happens.

Oh, it will be t alright.  I knew that already.  The question was
whether you could explicitly set/customize it to nil and then see
whether you can still see the error sometimes, or whether this makes it
disappear reliably.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum