gnus quietly quits in background?

gnus quietly quits in background?

[Eric Abrahamsen]

I've been keeping up to date with the Ma Gnus development branch, and a
couple of days ago I started getting a very strange error. While
browsing articles in a group (so far it's only happened in NNTP groups),
I'll suddenly start getting the error "No buffer named *Group*" any time
I try to scroll an article or open a new article. Sure enough, gnus
seems to have quietly crashed in the background: I've got my open
summary and article buffers, but the *Group* buffer and all the other
gnus-related buffers have silently gone away, and I'm not able to
perform any normal gnus operations in the summary/article buffers.

I don't know how to trigger this -- it's been happening occasionally as
I read news, maybe once for every ten minutes of news reading. No other
error pops up.

I tried isolating by starting emacs with the -Q option and adding the
gnus codebase to load-path, but was unable to start gnus at all --
though all my gnus-related files are in standard locations it's
apparently too tied to my .emacs configuration to get out of the gate.

I guess I'll leave it at that, with some direction I hope I can provide
some more useful information…

Thanks,
Eric

-- 
GNU Emacs 24.0.93.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
 of 2012-02-16
Ma Gnus v0.4

Re: gnus quietly quits in background?

[Eric Abrahamsen]

On Sat, Feb 18 2012, Eric Abrahamsen wrote:

> I've been keeping up to date with the Ma Gnus development branch, and a
> couple of days ago I started getting a very strange error. While
> browsing articles in a group (so far it's only happened in NNTP groups),
> I'll suddenly start getting the error "No buffer named *Group*" any time
> I try to scroll an article or open a new article. Sure enough, gnus
> seems to have quietly crashed in the background: I've got my open
> summary and article buffers, but the *Group* buffer and all the other
> gnus-related buffers have silently gone away, and I'm not able to
> perform any normal gnus operations in the summary/article buffers.

It's possible this is only happening when reading a gwene RSS group:
nntp+news.gwene.org:gwene.com.chinasmack, though I guess it seems
unlikely that there's something special about that particular group.
This time I had debug-on-error set, and got this not-very-helpful trace:

Debugger entered--Lisp error: (error "No buffer named *Group*")
  gnus-set-global-variables()
  gnus-summary-next-page(nil)
  call-interactively(gnus-summary-next-page nil nil)


-- 
GNU Emacs 24.0.93.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
 of 2012-02-16
Ma Gnus v0.4

Re: gnus quietly quits in background?

[Adam Sjøgren]

On Sat, 18 Feb 2012 16:51:25 +0800, Eric wrote:

> While browsing articles in a group (so far it's only happened in NNTP
> groups), I'll suddenly start getting the error "No buffer named
> *Group*" any time I try to scroll an article or open a new article.

Just a data point: This happened to me as well yesterday - just once.

Do you run any demons? (I run gnus-demon-scan-news 5 5).


  Best regards,

    Adam

 GNU Emacs 24.0.93.1 (x86_64-pc-linux-gnu, GTK+ Version 3.2.3) of
   2012-02-16 on zelenka, modified by Debian
 Ma Gnus v0.4 (f603f1b9)

-- 
 "My internal clock is on Tokyo time."                        Adam Sjøgren
                                                         asjo@koldfront.dk

Re: gnus quietly quits in background?

[Eric Abrahamsen]

On Sat, Feb 18 2012, Adam Sjøgren wrote:

> On Sat, 18 Feb 2012 16:51:25 +0800, Eric wrote:
>
>> While browsing articles in a group (so far it's only happened in NNTP
>> groups), I'll suddenly start getting the error "No buffer named
>> *Group*" any time I try to scroll an article or open a new article.
>
> Just a data point: This happened to me as well yesterday - just once.
>
> Do you run any demons? (I run gnus-demon-scan-news 5 5).

Thanks for this… And no, I don't use the demon or (as far as I know) any
automatic or timed functions.

-- 
GNU Emacs 24.0.93.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
 of 2012-02-16 on pellet
Ma Gnus v0.4

Re: gnus quietly quits in background?

[Antoine Levitt]

18/02/12 09:51, Eric Abrahamsen
> I've been keeping up to date with the Ma Gnus development branch, and a
> couple of days ago I started getting a very strange error. While
> browsing articles in a group (so far it's only happened in NNTP groups),
> I'll suddenly start getting the error "No buffer named *Group*" any time
> I try to scroll an article or open a new article. Sure enough, gnus
> seems to have quietly crashed in the background: I've got my open
> summary and article buffers, but the *Group* buffer and all the other
> gnus-related buffers have silently gone away, and I'm not able to
> perform any normal gnus operations in the summary/article buffers.
>
> I don't know how to trigger this -- it's been happening occasionally as
> I read news, maybe once for every ten minutes of news reading. No other
> error pops up.
>
> I tried isolating by starting emacs with the -Q option and adding the
> gnus codebase to load-path, but was unable to start gnus at all --
> though all my gnus-related files are in standard locations it's
> apparently too tied to my .emacs configuration to get out of the gate.
>
> I guess I'll leave it at that, with some direction I hope I can provide
> some more useful information…
>
> Thanks,
> Eric

I got that too once yesterday, on a particularly slow RSS group. I don't
use ma gnus though, just emacs trunk.

Re: gnus quietly quits in background?

[Steinar Bang]

Does it happen frequently enough that is feasible to locate the
offending commit, using git bisect?

Re: gnus quietly quits in background?

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I'll suddenly start getting the error "No buffer named *Group*" any time
> I try to scroll an article or open a new article.

I just had a summary buffer disappear on me.  So I think something is
killing random Gnus buffers.

This happened while I was reading a Gwene group, so it could be url.el
related.  Did everybody else who saw this have pictures displayed?

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: gnus quietly quits in background?

[Antoine Levitt]

18/02/12 13:59, Lars Ingebrigtsen
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I'll suddenly start getting the error "No buffer named *Group*" any time
>> I try to scroll an article or open a new article.
>
> I just had a summary buffer disappear on me.  So I think something is
> killing random Gnus buffers.

The horror.

I think it also killed one or two innocent ERC buffers that were passing
by. These atrocities must stop.

> This happened while I was reading a Gwene group, so it could be url.el
> related.  Did everybody else who saw this have pictures displayed?

Yes for me.

Re: gnus quietly quits in background?

[Lars Ingebrigtsen]

Antoine Levitt <antoine.levitt@gmail.com> writes:

>> This happened while I was reading a Gwene group, so it could be url.el
>> related.  Did everybody else who saw this have pictures displayed?
>
> Yes for me.

I've now pushed something to safeguard a potential (but unlikely) "kill
a random buffer" thing in shr.el.  If everybody could upgrade and see
whether the problem still exist, that would be nice.

It's rather unlikely that this will fix the problem, but I've been
staring at the code, and I can't really imagine anywhere else if might
be killing off random buffers...

My thought is that there's a (kill-buffer (current-buffer))
... somewhere ... in the shr/url code.  And that the current buffer is
the wrong buffer.  It's happened before in the url code.  But I've
grepped and grepped, and I can't see any likely candidates.  And it
happens so rarely that it's virtually impossible to bisect.

Perhaps I should just read the commit messages for Emacs and Gnus for
the last week instead?

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: gnus quietly quits in background?

[Eric Abrahamsen]

On Sat, Feb 18 2012, Lars Ingebrigtsen wrote:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I'll suddenly start getting the error "No buffer named *Group*" any time
>> I try to scroll an article or open a new article.
>
> I just had a summary buffer disappear on me.  So I think something is
> killing random Gnus buffers.
>
> This happened while I was reading a Gwene group, so it could be url.el
> related.  Did everybody else who saw this have pictures displayed?

Yes, I believe so. I'll update and see if that helps...

-- 
GNU Emacs 24.0.93.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
 of 2012-02-16 on pellet
Ma Gnus v0.4

Re: gnus quietly quits in background?

[Eric Abrahamsen]

On Sun, Feb 19 2012, Lars Ingebrigtsen wrote:

> Antoine Levitt <antoine.levitt@gmail.com> writes:
>
>>> This happened while I was reading a Gwene group, so it could be url.el
>>> related.  Did everybody else who saw this have pictures displayed?
>>
>> Yes for me.
>
> I've now pushed something to safeguard a potential (but unlikely) "kill
> a random buffer" thing in shr.el.  If everybody could upgrade and see
> whether the problem still exist, that would be nice.

Nope, I got it again right away -- first time I visited an article with
an image in it…

-- 
GNU Emacs 24.0.93.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
 of 2012-02-16 on pellet
Ma Gnus v0.4

Re: gnus quietly quits in background?

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Nope, I got it again right away -- first time I visited an article with
> an image in it…

Right.  I've now instrumented `kill-buffer' so that it'll give me a
backtrace when something tries to kill the group buffer.

Could you try this, too?

(defvar real-kill-buffer (symbol-function 'kill-buffer))
(defun kill-buffer (&optional buffer)
  (when (and (bufferp buffer)
	     (equal (buffer-name buffer) "*Group*"))
    (debug))
  (funcall real-kill-buffer buffer))

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: gnus quietly quits in background?

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Right.  I've now instrumented `kill-buffer' so that it'll give me a
> backtrace when something tries to kill the group buffer.

And I got a backtrace.

The code is:

(defun gnus-html-image-fetched (status buffer image)
  "Callback function called when image has been fetched."
  (unless (plist-get status :error)
[...]
    )
  (kill-buffer (current-buffer)))

So when we get an :error, sometimes the http buffer doesn't exist?
That's just weird.

Debugger entered: nil
  (progn (debug))
  (if (and (bufferp buffer) (or (equal (buffer-name buffer) "*Group*") (and (> (length (buffer-name buffer)) 10) (equal (substring (buffer-name buffer) 0 8) "*Summary")))) (progn (debug)))
  (when (and (bufferp buffer) (or (equal (buffer-name buffer) "*Group*") (and (> (length (buffer-name buffer)) 10) (equal (substring (buffer-name buffer) 0 8) "*Summary")))) (debug))
  kill-buffer(#<buffer *Summary nntp+news.gmane.org:gwene.com.hacker-news.full*>)
  gnus-html-image-fetched((:error (error connection-failed "deleted\n" :host "gifninja.com" :service 80)) nil ("http://gifninja.com/animatedgifs/647830/buffer.gif"))
  apply(gnus-html-image-fetched ((:error (error connection-failed "deleted\n" :host "gifninja.com" :service 80)) nil ("http://gifninja.com/animatedgifs/647830/buffer.gif")))
  url-queue-callback-function((:error (error connection-failed "deleted\n" :host "gifninja.com" :service 80)) [cl-struct-url-queue "http://gifninja.com/animatedgifs/647830/buffer.gif" gnus-html-image-fetched (nil ("http://gifninja.com/animatedgifs/647830/buffer.gif")) t #<killed buffer> 1329640750.369599 nil t])
  apply(url-queue-callback-function ((:error (error connection-failed "deleted\n" :host "gifninja.com" :service 80)) [cl-struct-url-queue "http://gifninja.com/animatedgifs/647830/buffer.gif" gnus-html-image-fetched (nil ("http://gifninja.com/animatedgifs/647830/buffer.gif")) t #<killed buffer> 1329640750.369599 nil t]))
  url-http-activate-callback()
  url-http-async-sentinel(#<process gifninja.com> "deleted\n")
  delete-process(#<process gifninja.com>)
  byte-code("\302\303\b\304H	>\204.

Re: gnus quietly quits in background?

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So when we get an :error, sometimes the http buffer doesn't exist?
> That's just weird.

It was due to a change I made in url-queue.el a few days ago to ensure
that it killed off the correct processes on connection errors.

This is now fixed in Emacs 24.

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: gnus quietly quits in background?

[Eric Abrahamsen]

On Sun, Feb 19 2012, Lars Ingebrigtsen wrote:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> So when we get an :error, sometimes the http buffer doesn't exist?
>> That's just weird.
>
> It was due to a change I made in url-queue.el a few days ago to ensure
> that it killed off the correct processes on connection errors.
>
> This is now fixed in Emacs 24.

I just updated both gnus and emacs 24, and am still having the problem…

-- 
GNU Emacs 24.0.93.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
 of 2012-02-16 on pellet
Ma Gnus v0.4

Re: gnus quietly quits in background?

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I just updated both gnus and emacs 24, and am still having the problem…

I'm not seeing it any more, though.

Could you eval the following and post the backtrace?

(defvar real-kill-buffer (symbol-function 'kill-buffer))
(defun kill-buffer (&optional buffer)
  (when (and (bufferp buffer)
	     (or (equal (buffer-name buffer) "*Group*")
		 (and (> (length (buffer-name buffer)) 10)
		      (equal (substring (buffer-name buffer) 0 8)
			     "*Summary"))))
    (debug))
  (funcall real-kill-buffer buffer))

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: gnus quietly quits in background?

[Eric Abrahamsen]

On Mon, Feb 20 2012, Lars Ingebrigtsen wrote:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I just updated both gnus and emacs 24, and am still having the problem…
>
> I'm not seeing it any more, though.
>
> Could you eval the following and post the backtrace?
>
> (defvar real-kill-buffer (symbol-function 'kill-buffer))
> (defun kill-buffer (&optional buffer)
>   (when (and (bufferp buffer)
> 	     (or (equal (buffer-name buffer) "*Group*")
> 		 (and (> (length (buffer-name buffer)) 10)
> 		      (equal (substring (buffer-name buffer) 0 8)
> 			     "*Summary"))))
>     (debug))
>   (funcall real-kill-buffer buffer))

I used the code from one of your earlier postings, as the above seems to
have its parens in the wrong spot (and I'm only getting the *Group*
buffer killed). The result:

Debugger entered: nil
  (progn (debug))
  (if (and (bufferp buffer) (equal (buffer-name buffer) "*Group*")) (progn (debug)))
  (when (and (bufferp buffer) (equal (buffer-name buffer) "*Group*")) (debug))
  kill-buffer(#<buffer *Group*>)
  gnus-html-image-fetched((:error (error connection-failed "deleted\n" :host "feeds.feedburner.com" :service 80)) #<buffer *Article nntp+news.gwene.org:gwene.com.arstechnica*> ("http://feeds.feedburner.com/~ff/arstechnica/index?i=FfBvJUcgQuo:srEXa6LOIl4:V_sGLiPBpWU" "*"))
  apply(gnus-html-image-fetched ((:error (error connection-failed "deleted\n" :host "feeds.feedburner.com" :service 80)) #<buffer *Article nntp+news.gwene.org:gwene.com.arstechnica*> ("http://feeds.feedburner.com/~ff/arstechnica/index?i=FfBvJUcgQuo:srEXa6LOIl4:V_sGLiPBpWU" "*")))
  url-queue-callback-function((:error (error connection-failed "deleted\n" :host "feeds.feedburner.com" :service 80)) [cl-struct-url-queue "http://feeds.feedburner.com/~ff/arstechnica/index?i=FfBvJUcgQuo:srEXa6LOIl4:V_sGLiPBpWU" gnus-html-image-fetched (#<buffer *Article nntp+news.gwene.org:gwene.com.arstechnica*> ("http://feeds.feedburner.com/~ff/arstechnica/index?i=FfBvJUcgQuo:srEXa6LOIl4:V_sGLiPBpWU" "*")) t #<killed buffer> 1329737310.316499 t t])
  apply(url-queue-callback-function ((:error (error connection-failed "deleted\n" :host "feeds.feedburner.com" :service 80)) [cl-struct-url-queue "http://feeds.feedburner.com/~ff/arstechnica/index?i=FfBvJUcgQuo:srEXa6LOIl4:V_sGLiPBpWU" gnus-html-image-fetched (#<buffer *Article nntp+news.gwene.org:gwene.com.arstechnica*> ("http://feeds.feedburner.com/~ff/arstechnica/index?i=FfBvJUcgQuo:srEXa6LOIl4:V_sGLiPBpWU" "*")) t #<killed buffer> 1329737310.316499 t t]))
  url-http-activate-callback()
  url-http-async-sentinel(#<process feeds.feedburner.com> "deleted\n")
  delete-process(#<process feeds.feedburner.com>)
  byte-code("\302\303\b\304H	>\204\0\305\306\307\310#\210\b\311H!!\207" [job cl-struct-url-queue-tags delete-process get-buffer-process 0 error "%s accessing a non-%s" url-queue-buffer url-queue 5] 6)
  url-queue-kill-job([cl-struct-url-queue "http://feeds.feedburner.com/~ff/arstechnica/index?i=FfBvJUcgQuo:srEXa6LOIl4:V_sGLiPBpWU" gnus-html-image-fetched (#<buffer *Article nntp+news.gwene.org:gwene.com.arstechnica*> ("http://feeds.feedburner.com/~ff/arstechnica/index?i=FfBvJUcgQuo:srEXa6LOIl4:V_sGLiPBpWU" "*")) t #<killed buffer> 1329737310.316499 t t])
  url-queue-prune-old-entries()
  url-queue-run-queue()
  apply(url-queue-run-queue nil)
  byte-code("r\301\b\302H\b\303H\"\210)\301\207" [timer apply 5 6] 4)
  timer-event-handler([t 0 0 10000 nil url-queue-run-queue nil idle])
  accept-process-output(#<process ibus-agent> 3.0 nil t)
  ibus-agent-receive(nil t)
  byte-code("\b\204\0\306\307\310\"\210\311\312\313\"\210\313r\314 q\210p\n\v\315=?\316 \f=\206&\317 \232<=>?=\204V\x0e>\203V\320 \204V\313>?@=\203N\321 \210\202V\x0e?@\321 \210)?@=\203s\x0e=\203i\x0eA?\202p\x0eA\203s\x0e<\204A\322\323@?#\210\324@!\203\244r@q\210A\247\203\243\x0eB\203\233\325\313!\210\326\313\327\"\210C\203\243\330 \210)<\204\256\331\332\333\217\210?@\n\206\275\x0eD\206\275\334 \211EF\236G\335\x0eG\211\rA@)\"AA\335\336G8\"AH\n\204\a\x0eE\x0eD\203\x01\322\337E\"\210\340G\233?\341?\340G8\"B\240\210\342\343\344\313\327$\210*=\204\"\x0e>\203\x01A\204\"\322\345?\"\210\331\346\347\217\210I\350\230\2036\313BA\247\2036\351\327!\210\352 \210=\204A\353 \210,\313DJ\204\202\x0eK\204\202\x0eL\354=\204\202\355\356!\203c\x0e.\354=\204\202\355\357!\203u\x0e/\203u\x0eM\360=\204\202\355\361!\205\217\x0e1\362=\205\217\x0eN\205\216\x0eO\205\216\x0eP?Q?=\203\233\363Q!\210\364\365!\203\317\x0eC\203\255\x0eR8\202\317\x0eN\203\271\x0eS8\202\317\x0e5\366=\203\307\367\370!\210\202\313\x0e58\367\365!\210\316 \f=?\205\360\x0eC\203\353\v\315=\203\353\371 \210\372 \210\373 \210\316 \353 )\207" [ibus-mode ibus-last-rejected-event ibus-buffer-group window-system ibus-selected-frame ibus-selected-display remove-hook post-command-hook ibus-check-current-buffer throw exit nil window-buffer x selected-frame ibus-get-x-display ibus-buffer-group-suitable-p ibus-destroy-imcontext ibus-log "buffer was changed from %S to %S" buffer-live-p ibus-change-focus ibus-agent-receive t ibus-cleanup-preedit err (ibus-change-x-display) ((error (byte-code "\303\304\b@\b\211AA)\203\0\bA\202\0\b\211A@)#\210\n\203!\305 \210\306\307\310\"\207" [err x ibus-mode ibus-message "%s: %s" ibus-mode-quit throw exit nil] 5))) ibus-buffer-group-identifier assoc 2 "inherit IMContext (buffer group: %s)" 3 delq add-hook kill-buffer-hook ibus-kill-buffer-function "new buffer was detected: %S" (ibus-create-imcontext) ((error (byte-code "\303\304\b@\b\211AA)\203\0\bA\202\0\b\211A@)#\210\n\203!\305 \210\306\307\310\"\207" [err x ibus-mode ibus-message "%s: %s" ibus-mode-quit throw exit nil] 5))) "" ibus-check-frame-focus ibus-set-keymap-parent ibus-update-cursor-color vi-mode boundp vip-current-mode vim-mode vim:normal-mode viper-current-state ...] 7)
  ibus-check-current-buffer()
  recursive-edit()
  debug()
  (progn (debug))
  (if (and (bufferp buffer) (equal (buffer-name buffer) "*Group*")) (progn (debug)))
  (when (and (bufferp buffer) (equal (buffer-name buffer) "*Group*")) (debug))
  kill-buffer(#<buffer *Group*>)
  gnus-html-image-fetched((:error (error connection-failed "deleted\n" :host "static.arstechnica.net" :service 80)) #<buffer *Article nntp+news.gwene.org:gwene.com.arstechnica*> ("http://static.arstechnica.net/brief_icons_new/apple-brief.png" "*"))
  apply(gnus-html-image-fetched ((:error (error connection-failed "deleted\n" :host "static.arstechnica.net" :service 80)) #<buffer *Article nntp+news.gwene.org:gwene.com.arstechnica*> ("http://static.arstechnica.net/brief_icons_new/apple-brief.png" "*")))
  url-queue-callback-function((:error (error connection-failed "deleted\n" :host "static.arstechnica.net" :service 80)) [cl-struct-url-queue "http://static.arstechnica.net/brief_icons_new/apple-brief.png" gnus-html-image-fetched (#<buffer *Article nntp+news.gwene.org:gwene.com.arstechnica*> ("http://static.arstechnica.net/brief_icons_new/apple-brief.png" "*")) t #<killed buffer> 1329737304.726624 t t])
  apply(url-queue-callback-function ((:error (error connection-failed "deleted\n" :host "static.arstechnica.net" :service 80)) [cl-struct-url-queue "http://static.arstechnica.net/brief_icons_new/apple-brief.png" gnus-html-image-fetched (#<buffer *Article nntp+news.gwene.org:gwene.com.arstechnica*> ("http://static.arstechnica.net/brief_icons_new/apple-brief.png" "*")) t #<killed buffer> 1329737304.726624 t t]))
  url-http-activate-callback()
  url-http-async-sentinel(#<process static.arstechnica.net> "deleted\n")
  delete-process(#<process static.arstechnica.net>)
  byte-code("\302\303\b\304H	>\204\0\305\306\307\310#\210\b\311H!!\207" [job cl-struct-url-queue-tags delete-process get-buffer-process 0 error "%s accessing a non-%s" url-queue-buffer url-queue 5] 6)
  url-queue-kill-job([cl-struct-url-queue "http://static.arstechnica.net/brief_icons_new/apple-brief.png" gnus-html-image-fetched (#<buffer *Article nntp+news.gwene.org:gwene.com.arstechnica*> ("http://static.arstechnica.net/brief_icons_new/apple-brief.png" "*")) t #<killed buffer> 1329737304.726624 t t])
  url-queue-prune-old-entries()
  url-queue-run-queue()
  url-queue-callback-function((:error (error connection-failed "deleted\n" :host "feedads.g.doubleclick.net" :service 80)) [cl-struct-url-queue "http://feedads.g.doubleclick.net/~at/O0zNR66IPTyJdvJGt2ocfkiE0yg/0/di" gnus-html-image-fetched (#<buffer *Article nntp+news.gwene.org:gwene.com.arstechnica*> ("http://feedads.g.doubleclick.net/~at/O0zNR66IPTyJdvJGt2ocfkiE0yg/0/di" "*")) t #<killed buffer> 1329737304.926084 t t])
  apply(url-queue-callback-function ((:error (error connection-failed "deleted\n" :host "feedads.g.doubleclick.net" :service 80)) [cl-struct-url-queue "http://feedads.g.doubleclick.net/~at/O0zNR66IPTyJdvJGt2ocfkiE0yg/0/di" gnus-html-image-fetched (#<buffer *Article nntp+news.gwene.org:gwene.com.arstechnica*> ("http://feedads.g.doubleclick.net/~at/O0zNR66IPTyJdvJGt2ocfkiE0yg/0/di" "*")) t #<killed buffer> 1329737304.926084 t t]))
  url-http-activate-callback()
  url-http-async-sentinel(#<process feedads.g.doubleclick.net> "deleted\n")
  delete-process(#<process feedads.g.doubleclick.net>)
  byte-code("\302\303\b\304H	>\204\0\305\306\307\310#\210\b\311H!!\207" [job cl-struct-url-queue-tags delete-process get-buffer-process 0 error "%s accessing a non-%s" url-queue-buffer url-queue 5] 6)
  url-queue-kill-job([cl-struct-url-queue "http://feedads.g.doubleclick.net/~at/O0zNR66IPTyJdvJGt2ocfkiE0yg/0/di" gnus-html-image-fetched (#<buffer *Article nntp+news.gwene.org:gwene.com.arstechnica*> ("http://feedads.g.doubleclick.net/~at/O0zNR66IPTyJdvJGt2ocfkiE0yg/0/di" "*")) t #<killed buffer> 1329737304.926084 t t])
  url-queue-remove-jobs-from-host("feedads.g.doubleclick.net")
  url-queue-callback-function((:error (error connection-failed "deleted\n" :host "feedads.g.doubleclick.net" :service 80)) [cl-struct-url-queue "http://feedads.g.doubleclick.net/~at/O0zNR66IPTyJdvJGt2ocfkiE0yg/1/di" gnus-html-image-fetched (#<buffer *Article nntp+news.gwene.org:gwene.com.arstechnica*> ("http://feedads.g.doubleclick.net/~at/O0zNR66IPTyJdvJGt2ocfkiE0yg/1/di" "*")) t #<killed buffer> 1329737305.311995 t t])
  apply(url-queue-callback-function ((:error (error connection-failed "deleted\n" :host "feedads.g.doubleclick.net" :service 80)) [cl-struct-url-queue "http://feedads.g.doubleclick.net/~at/O0zNR66IPTyJdvJGt2ocfkiE0yg/1/di" gnus-html-image-fetched (#<buffer *Article nntp+news.gwene.org:gwene.com.arstechnica*> ("http://feedads.g.doubleclick.net/~at/O0zNR66IPTyJdvJGt2ocfkiE0yg/1/di" "*")) t #<killed buffer> 1329737305.311995 t t]))
  url-http-activate-callback()
  url-http-async-sentinel(#<process feedads.g.doubleclick.net<1>> "deleted\n")
  delete-process(#<process feedads.g.doubleclick.net<1>>)
  byte-code("\302\303\b\304H	>\204\0\305\306\307\310#\210\b\311H!!\207" [job cl-struct-url-queue-tags delete-process get-buffer-process 0 error "%s accessing a non-%s" url-queue-buffer url-queue 5] 6)
  url-queue-kill-job([cl-struct-url-queue "http://feedads.g.doubleclick.net/~at/O0zNR66IPTyJdvJGt2ocfkiE0yg/1/di" gnus-html-image-fetched (#<buffer *Article nntp+news.gwene.org:gwene.com.arstechnica*> ("http://feedads.g.doubleclick.net/~at/O0zNR66IPTyJdvJGt2ocfkiE0yg/1/di" "*")) t #<killed buffer> 1329737305.311995 t t])
  url-queue-prune-old-entries()
  url-queue-run-queue()
  apply(url-queue-run-queue nil)
  byte-code("r\301\b\302H\b\303H\"\210)\301\207" [timer apply 5 6] 4)
  timer-event-handler([t 0 0 10000 nil url-queue-run-queue nil idle])


-- 
GNU Emacs 24.0.93.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
 of 2012-02-16 on pellet
Ma Gnus v0.4

Re: gnus quietly quits in background?

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I used the code from one of your earlier postings, as the above seems to
> have its parens in the wrong spot (and I'm only getting the *Group*
> buffer killed). The result:

Ah.  It looks like the code that's killing off the processes also
trigger the sentinel, which is also killing the buffers.

That's a bit too much killing.  This may now be fixed in Emacs 24 --
could you check?

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: gnus quietly quits in background?

[Eric Abrahamsen]

On Mon, Feb 20 2012, Lars Ingebrigtsen wrote:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I used the code from one of your earlier postings, as the above seems to
>> have its parens in the wrong spot (and I'm only getting the *Group*
>> buffer killed). The result:
>
> Ah.  It looks like the code that's killing off the processes also
> trigger the sentinel, which is also killing the buffers.
>
> That's a bit too much killing.  This may now be fixed in Emacs 24 --
> could you check?

Looks good! So far, anyway…

-- 
GNU Emacs 24.0.93.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
 of 2012-02-21 on pellet
Ma Gnus v0.4