GNU bug report logs - #9075
expecting a list, got a vector

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9075 in the body.
You can then email your comments to 9075 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dave Abrahams <dave <at> boostpro.com>
To: submit <at> debbugs.gnu.org (The Gnus Bugfixing Girls + Boys)
Subject: expecting a list, got a vector
Date: Thu, 14 Jul 2011 00:22:36 -0400

Debugger entered--Lisp error: (wrong-type-argument listp [32470 "Re: gist gist: 973698" "tomprince <reply+g-973698-ecfb1d0fb7cd69b91953035c83e9238c54bfb756 <at> reply.github.com>" #("Mon, 16 May 2011 07:09:07 -0700" 0 1 (gnus-time (19921 12291))) "<gist/973698/31070 <at> github.com>" "<gist/973698 <at> github.com>" 2039 18 nil ((Message-Id . "<gist/973698/31070 <at> github.com>") (Message-ID . "<gist/973698/31070 <at> github.com>") (To . "dave <at> boostpro.com"))])
  gnus-remove-thread("<m2hb6qy7ry.fsf <at> pluto.luannocracy.com>")
  gnus-rebuild-thread("<m2hb6qy7ry.fsf <at> pluto.luannocracy.com>" nil)
  gnus-summary-insert-subject(-1 nil t)
  gnus-summary-goto-subject(-1 t)
  gnus-summary-goto-article(-1 nil t)
  gnus-summary-refer-article("<m2hb6qy7ry.fsf <at> pluto.luannocracy.com>")
  gnus-summary-refer-parent-article(1)
  call-interactively(gnus-summary-refer-parent-article nil nil)



No Gnus v0.18
GNU Emacs 23.3.1 (x86_64-apple-darwin, NS apple-appkit-1038.35)
 of 2011-03-09 on black.porkrind.org
200 news.gmane.org InterNetNews NNRP server INN 2.5.1 ready (posting ok)
101 Capability list:
VERSION 2
IMPLEMENTATION INN 2.5.1
AUTHINFO USER
HDR
LIST ACTIVE ACTIVE.TIMES DISTRIB.PATS HEADERS NEWSGROUPS OVERVIEW.FMT
OVER
POST
READER
STARTTLS
.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Message #8 received at 9075 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Dave Abrahams <dave <at> boostpro.com>
Cc: 9075 <at> debbugs.gnu.org
Subject: Re: expecting a list, got a vector
Date: Tue, 19 Jul 2011 19:39:50 +0200

Dave Abrahams <dave <at> boostpro.com> writes:

> Debugger entered--Lisp error: (wrong-type-argument listp [32470 "Re: gist gist: 973698" "tomprince <reply+g-973698-ecfb1d0fb7cd69b91953035c83e9238c54bfb756 <at> reply.github.com>" #("Mon, 16 May 2011 07:09:07 -0700" 0 1 (gnus-time (19921 12291))) "<gist/973698/31070 <at> github.com>" "<gist/973698 <at> github.com>" 2039 18 nil ((Message-Id . "<gist/973698/31070 <at> github.com>") (Message-ID . "<gist/973698/31070 <at> github.com>") (To . "dave <at> boostpro.com"))])
>   gnus-remove-thread("<m2hb6qy7ry.fsf <at> pluto.luannocracy.com>")
>   gnus-rebuild-thread("<m2hb6qy7ry.fsf <at> pluto.luannocracy.com>" nil)
>   gnus-summary-insert-subject(-1 nil t)
>   gnus-summary-goto-subject(-1 t)
>   gnus-summary-goto-article(-1 nil t)
>   gnus-summary-refer-article("<m2hb6qy7ry.fsf <at> pluto.luannocracy.com>")

I'm unable to reproduce this.

Could you (load "gnus-sum") to get an unloaded Gnus?  That should give
me a more detailed backtrace.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #11 received at 9075 <at> debbugs.gnu.org (full text, mbox):

From: Dave Abrahams <dave <at> boostpro.com>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: 9075 <at> debbugs.gnu.org
Subject: Re: expecting a list, got a vector
Date: Thu, 21 Jul 2011 19:33:39 -0400

on Tue Jul 19 2011, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:

> Dave Abrahams <dave <at> boostpro.com> writes:
>
>> Debugger entered--Lisp error: (wrong-type-argument listp [32470 "Re:
>> gist gist: 973698" "tomprince
>> <reply+g-973698-ecfb1d0fb7cd69b91953035c83e9238c54bfb756 <at> reply.github.com>"
>> #("Mon, 16 May 2011 07:09:07 -0700" 0 1 (gnus-time (19921 12291)))
>> "<gist/973698/31070 <at> github.com>" "<gist/973698 <at> github.com>" 2039 18
>> nil ((Message-Id . "<gist/973698/31070 <at> github.com>") (Message-ID
>> . "<gist/973698/31070 <at> github.com>") (To . "dave <at> boostpro.com"))])
>>   gnus-remove-thread("<m2hb6qy7ry.fsf <at> pluto.luannocracy.com>")
>>   gnus-rebuild-thread("<m2hb6qy7ry.fsf <at> pluto.luannocracy.com>" nil)
>>   gnus-summary-insert-subject(-1 nil t)
>>   gnus-summary-goto-subject(-1 t)
>>   gnus-summary-goto-article(-1 nil t)
>>   gnus-summary-refer-article("<m2hb6qy7ry.fsf <at> pluto.luannocracy.com>")
>
> I'm unable to reproduce this.
>
> Could you (load "gnus-sum") to get an unloaded Gnus?  That should give
> me a more detailed backtrace.

Do you mean an uncompiled Gnus?  Wouldn't I have to (load "gnus-sum.el")
for that?

Unfortunately, now I can't reproduce it either.  I think I may have made
it go away with some drastic action I took like tossing my Agent data.

It's a longstanding problem that Gnus gets into odd states that result
in otherwise-unreproducible behavior.  It's easy to understand how a
system with so many layers of chacheing could be vulnerable to that kind
of problem... I wonder if it's possible to add some assertions to Gnus
so that these odd states can be caught earlier.

One theory I've been mulling over recently is that these conditions
mostly happen due to incomplete error handling.  It's not uncommon that
some operation gets stuck, or just takes too long, and I have to
interrupt it either with `C-g' or (much more rarely) by killing some
process.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Message #16 received at 9075 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Dave Abrahams <dave <at> boostpro.com>
Cc: 9075 <at> debbugs.gnu.org
Subject: Re: expecting a list, got a vector
Date: Sun, 31 Jul 2011 17:26:52 +0200

Dave Abrahams <dave <at> boostpro.com> writes:

> Do you mean an uncompiled Gnus?  Wouldn't I have to (load "gnus-sum.el")
> for that?

Yes.

> Unfortunately, now I can't reproduce it either.  I think I may have made
> it go away with some drastic action I took like tossing my Agent data.

If it's Agent-related, that would make more sense...  I still haven't
gotten around to really digging into the nnimap/Agent interaction
problems.  I should just switch on agentising for all my nnimap groups
to experience the problems myself.

> One theory I've been mulling over recently is that these conditions
> mostly happen due to incomplete error handling.  It's not uncommon that
> some operation gets stuck, or just takes too long, and I have to
> interrupt it either with `C-g' or (much more rarely) by killing some
> process.

If you `C-g', Gnus is likely to end up in an odd state.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #19 received at 9075 <at> debbugs.gnu.org (full text, mbox):

From: Dave Abrahams <dave <at> boostpro.com>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: 9075 <at> debbugs.gnu.org
Subject: Re: expecting a list, got a vector
Date: Sun, 31 Jul 2011 12:56:51 -0400

on Sun Jul 31 2011, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:

> Dave Abrahams <dave <at> boostpro.com> writes:
>
>> One theory I've been mulling over recently is that these conditions
>> mostly happen due to incomplete error handling.  It's not uncommon that
>> some operation gets stuck, or just takes too long, and I have to
>> interrupt it either with `C-g' or (much more rarely) by killing some
>> process.
>
> If you `C-g', Gnus is likely to end up in an odd state.

Well, I think we need to fix that.  I have to `C-g' to get unstuck on a
daily basis.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Message #22 received at 9075 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dave Abrahams <dave <at> boostpro.com>
Cc: 9075 <at> debbugs.gnu.org
Subject: Re: expecting a list, got a vector
Date: Sun, 31 Jul 2011 19:32:39 +0200

Dave Abrahams <dave <at> boostpro.com> writes:

> Well, I think we need to fix that.  I have to `C-g' to get unstuck on a
> daily basis.

You shouldn't have to.  When do you have to `C-g'?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #25 received at 9075 <at> debbugs.gnu.org (full text, mbox):

From: Dave Abrahams <dave <at> boostpro.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 9075 <at> debbugs.gnu.org
Subject: Re: expecting a list, got a vector
Date: Sun, 31 Jul 2011 15:17:16 -0400

On Sun, Jul 31, 2011 at 1:32 PM, Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> Dave Abrahams <dave <at> boostpro.com> writes:
>
>> Well, I think we need to fix that.  I have to `C-g' to get unstuck on a
>> daily basis.
>
> You shouldn't have to.  When do you have to `C-g'?

It's fairly common when I do a `G' from the group buffer for
everything to get stuck just after nnimap seems to have collected all
its data from the server (I presume that's what's going on from the
message about how many bytes have been read).


-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Message #28 received at 9075 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dave Abrahams <dave <at> boostpro.com>
Cc: 9075 <at> debbugs.gnu.org
Subject: Re: expecting a list, got a vector
Date: Tue, 02 Aug 2011 16:01:04 +0200

Dave Abrahams <dave <at> boostpro.com> writes:

> It's fairly common when I do a `G' from the group buffer for
> everything to get stuck just after nnimap seems to have collected all
> its data from the server (I presume that's what's going on from the
> message about how many bytes have been read).

Can you (setq debug-on-quit t) and see where it hangs?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #31 received at 9075 <at> debbugs.gnu.org (full text, mbox):

From: Dave Abrahams <dave <at> boostpro.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 9075 <at> debbugs.gnu.org
Subject: Re: expecting a list, got a vector
Date: Tue, 02 Aug 2011 10:14:44 -0400

on Tue Aug 02 2011, Lars Ingebrigtsen <larsi-AT-gnus.org> wrote:

> Dave Abrahams <dave <at> boostpro.com> writes:
>
>> It's fairly common when I do a `G' from the group buffer for
>> everything to get stuck just after nnimap seems to have collected all
>> its data from the server (I presume that's what's going on from the
>> message about how many bytes have been read).
>
> Can you (setq debug-on-quit t) and see where it hangs?

Well, yeah, but as you know debug-on-quit is a PITA when you're not
trying to debug anything, and the problem intermittent.  So there's no
guarantee I'll maintain patience with debug-on-quit long enough to see
it.  But I'll try.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Message #34 received at 9075 <at> debbugs.gnu.org (full text, mbox):

From: Dave Abrahams <dave <at> boostpro.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 9075 <at> debbugs.gnu.org
Subject: Re: expecting a list, got a vector
Date: Tue, 02 Aug 2011 13:25:50 -0400

on Tue Aug 02 2011, Lars Ingebrigtsen <larsi-AT-gnus.org> wrote:

> Dave Abrahams <dave <at> boostpro.com> writes:
>
>> It's fairly common when I do a `G' from the group buffer for
>> everything to get stuck just after nnimap seems to have collected all
>> its data from the server (I presume that's what's going on from the
>> message about how many bytes have been read).
>
> Can you (setq debug-on-quit t) and see where it hangs?

Here's an example:

  byte-code("\203

Ugh!  I had an example in the backtrace buffer and copied it to kill,
but a null character embedded in the bytecode cut it off.

Ah, saved by browse-kill-ring.  I replaced the null with "^@":

  byte-code("\203^@\302\303!\210\304	!\210\305\207" [debug-on-quit process debug "Quit" delete-process nil] 2)
  nnimap-wait-for-response(259)
  nnimap-get-response(259)
  nnimap-command("UID SEARCH SENTBEFORE %s" "26-JUL-2011")
  nnimap-find-expired-articles("INBOX")
  nnimap-request-expire-articles((36507 36511 36514 36515 36516 36517 36518 36519 36520 36522 36523 36529 36531 36532 36533 36535 36536 36537 36538 36539 36540 36542 36543 36544 36545 36546 36547 36548 36550 36563 36564 36566 36568 36569 36570 36571 36572 36573 36574 36575 36576 36577 36578 36579 36580 36581 36582 36583 36584 36585 ...) "INBOX" "BoostPro" nil)
  gnus-request-expire-articles((36507 36511 36514 36515 36516 36517 36518 36519 36520 36522 36523 36529 36531 36532 36533 36535 36536 36537 36538 36539 36540 36542 36543 36544 36545 36546 36547 36548 36550 36563 36564 36566 36568 36569 36570 36571 36572 36573 36574 36575 36576 36577 36578 36579 36580 36581 36582 36583 36584 36585 ...) "INBOX")
  gnus-summary-expire-articles()
  run-hooks(gnus-summary-prepare-exit-hook)
  apply(run-hooks gnus-summary-prepare-exit-hook)
  gnus-run-hooks(gnus-summary-prepare-exit-hook)
  gnus-summary-exit(nil leave-hidden)
  gnus-summary-reselect-current-group(nil t)
  gnus-summary-rescan-group(nil)
  call-interactively(gnus-summary-rescan-group nil nil)


-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Message #37 received at 9075 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Dave Abrahams <dave <at> boostpro.com>
Cc: 9075 <at> debbugs.gnu.org
Subject: Re: expecting a list, got a vector
Date: Tue, 02 Aug 2011 19:33:13 +0200

Dave Abrahams <dave <at> boostpro.com> writes:

> Here's an example:
>
>   byte-code("\203
>
> Ugh!  I had an example in the backtrace buffer and copied it to kill,
> but a null character embedded in the bytecode cut it off.
>
> Ah, saved by browse-kill-ring.  I replaced the null with "^@":
>
>   byte-code("\203^@\302\303!\210\304 !\210\305\207" [debug-on-quit
> process debug "Quit" delete-process nil] 2)
>   nnimap-wait-for-response(259)
>   nnimap-get-response(259)
>   nnimap-command("UID SEARCH SENTBEFORE %s" "26-JUL-2011")
>   nnimap-find-expired-articles("INBOX")

What's in the "*nnimap ...*" buffer when this happens?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #40 received at 9075 <at> debbugs.gnu.org (full text, mbox):

From: Dave Abrahams <dave <at> boostpro.com>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: 9075 <at> debbugs.gnu.org
Subject: Re: expecting a list, got a vector
Date: Tue, 02 Aug 2011 13:50:38 -0400

on Tue Aug 02 2011, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:

> Dave Abrahams <dave <at> boostpro.com> writes:
>
>> Here's an example:
>>
>>   byte-code("\203
>>
>> Ugh!  I had an example in the backtrace buffer and copied it to kill,
>> but a null character embedded in the bytecode cut it off.
>>
>> Ah, saved by browse-kill-ring.  I replaced the null with "^@":
>>
>>   byte-code("\203^@\302\303!\210\304 !\210\305\207" [debug-on-quit
>> process debug "Quit" delete-process nil] 2)
>>   nnimap-wait-for-response(259)
>>   nnimap-get-response(259)
>>   nnimap-command("UID SEARCH SENTBEFORE %s" "26-JUL-2011")
>>   nnimap-find-expired-articles("INBOX")
>
> What's in the "*nnimap ...*" buffer when this happens?

I don't know.  It happens in varied circumstances and of course I've
done things in my Gnus session since.  Maybe next time I'll just fire up
a new emacs and keep the failed state around.

I have 3 of those *nnimap ...* buffers around at the moment.  The only
suspicious one contains:

--8<---------------cut here---------------start------------->8---
* SEARCH 32470 32592 34694 34852 34982 34995 34999 35185 35347 35355 35390 35395 35412 35438 35495 35643 35715 35763 35784 35810 35866 35867 35871 35872 35873 35874 35875 35876 35880 35885 35886 35888 35889 35896 35911 35916 35917 35918 35919 35927 35928 35931 35933 35934 35935 35940 35941 35942 35943 35946 35947 35949 35950 35951 35952 35953 35954 35956 35962 35964 35965 35966 35970 35971 35973 35976 35979 35981 35982 35984 35985 35987 35989 35990 35991 35992 35993 35994 35996 35997 35998 36001 36002 36003 36004 36014 36017 36018 36019 36020 36022 36024 36025 36045 36050 36051 36052 36053 36054 36059 36060 36061 36063 36064 36065 36069 36076 36077 36079 36080 36081 36082 36083 36084 36085 36088 36089 36093 36095 36096 36097 36098 36099 36101 36103 36104 36105 36106 36107 36108 36109 36110 36111 36112 36113 36114 36115 36116 36117 36118 36119 36120 36121 36122 36123 36124 36125 36126 36127 36128 36129 36130 36131 36132 36133 36134 36135 36136 36137 36138 36139 36140 36141 36142 36143 36144 36145 36146 36147 36148 36149 36150 36151 36152 36153 36154 36155 36156 36157 36158 36159 36160 36161 36162 36163 36164 36165 36166 36167 36168 36169 36170 36171 36172 36173 36174 36175 36176 36177 36178 36179 36180 36181 36182 36183 36184 36185 36186 36187 36188 36189 36190 36191 36192 36193 36194 36195 36196 36197 36198 36199 36200 36201 36202 36203 36204 36205 36206 36207 36208 36209 36210 36211 36212 36213 36214 36215 36216 36217 36218 36219 36220 36221 36222 36223 36224 36225 36226 36227 36228 36229 36230 36231 36232 36233 36234 36235 36236 36237 36238 36239 36240 36241 36242 36243 36244 36245 36246 36247 36248 36249 36250 36251 36252 36253 36254 36255 36256 36257 36258 36259 36260 36261 36262 36263 36264 36265 36266 36267 36268 36269 36270 36271 36272 36273 36274 36275 36276 36277 36278 36279 36280 36281 36282 36283 36284 36285 36286 36287 36288 36289 36290 36291 36292 36293 36294 36295 36296 36297 36298 36299 36300 36301 36302 36303 36304 36307 36308 36309 36310 36311 36312 36313 36314 36315 36316 36317 36318 36319 36320 36321 36333 36335 36336 36340 36349 36350 36351 36352 36353 36354 36355 36356 36357 36360 36364 36367 36370 36371 36372 36377 36381 36382 36383 36384 36385 36388 36391 36393 36400 36406 36407 36408 36410 36411 36412 36413 36420 36424 36425 36428 36429 36430 36431 36435 36442 36445 36448
169 OK SEARCH completed (Success)
* 681 EXISTS
170 OK Success
172 OK Success
174 OK Success
176 OK Success
178 OK Success
180 OK Success
*** Fatal error: A TLS packet with unexpected length was received.
*** Server has terminated the connection abnormally.

Process *nnimap* exited abnormally with code 1
--8<---------------cut here---------------end--------------->8---



-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Message #43 received at 9075 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Dave Abrahams <dave <at> boostpro.com>
Cc: 9075 <at> debbugs.gnu.org
Subject: Re: expecting a list, got a vector
Date: Tue, 02 Aug 2011 20:53:43 +0200

Dave Abrahams <dave <at> boostpro.com> writes:

> I don't know.  It happens in varied circumstances and of course I've
> done things in my Gnus session since.  Maybe next time I'll just fire up
> a new emacs and keep the failed state around.

That would help.

> I have 3 of those *nnimap ...* buffers around at the moment.  The only
> suspicious one contains:

[...]

> 180 OK Success
> *** Fatal error: A TLS packet with unexpected length was received.
> *** Server has terminated the connection abnormally.
>
> Process *nnimap* exited abnormally with code 1

That's the normal "the server has closed the connection" message.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #46 received at 9075 <at> debbugs.gnu.org (full text, mbox):

From: Dave Abrahams <dave <at> boostpro.com>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: 9075 <at> debbugs.gnu.org
Subject: Re: expecting a list, got a vector
Date: Mon, 15 Aug 2011 11:19:20 -0400

on Tue Aug 02 2011, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:

> Dave Abrahams <dave <at> boostpro.com> writes:
>
>> Here's an example:
>>
>>   byte-code("\203
>>
>> Ugh!  I had an example in the backtrace buffer and copied it to kill,
>> but a null character embedded in the bytecode cut it off.
>>
>> Ah, saved by browse-kill-ring.  I replaced the null with "^@":
>>
>>   byte-code("\203^@\302\303!\210\304 !\210\305\207" [debug-on-quit
>> process debug "Quit" delete-process nil] 2)
>>   nnimap-wait-for-response(259)
>>   nnimap-get-response(259)
>>   nnimap-command("UID SEARCH SENTBEFORE %s" "26-JUL-2011")
>>   nnimap-find-expired-articles("INBOX")
>
> What's in the "*nnimap ...*" buffer when this happens?

I don't know, and can't reproduce it, so you may as well close this one.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Message #51 received at 9075 <at> debbugs.gnu.org (full text, mbox):

From: Dave Abrahams <dave <at> boostpro.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 9075 <at> debbugs.gnu.org
Subject: Re: expecting a list, got a vector
Date: Sun, 04 Sep 2011 17:29:17 -0800

on Tue Aug 02 2011, Lars Ingebrigtsen <larsi-AT-gnus.org> wrote:

> Dave Abrahams <dave <at> boostpro.com> writes:
>
>> It's fairly common when I do a `G' from the group buffer for
>> everything to get stuck just after nnimap seems to have collected all
>> its data from the server (I presume that's what's going on from the
>> message about how many bytes have been read).
>
> Can you (setq debug-on-quit t) and see where it hangs?

Here's another example:

  delq(16560 (897 946 947 949 962 963 1775 13969 14020 14070 16561 16562 16563 16564 16565 16566 16567 16568 16569 16570 16571 16572 16573 16574 16575 16576 16577 16578 16579 16580 16581 16582 16583 16584 16585 16586 16587 16588 16589 16590 16591 16592 16593 16594 16595 16596 16597 16598 16599 16600 ...))
  (setq list1 (delq (car list2) list1))
  (while list2 (setq list1 (delq ... list1)) (setq list2 (cdr list2)))
  (let ((list1 ...)) (while list2 (setq list1 ...) (setq list2 ...)) list1)
  gnus-set-difference((1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 ...) (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 ...))
  nnimap-update-info(("[Gmail].All Mail" 6 ((1 . 896) (898 . 945) 948 (950 . 961) (964 . 1774) (1776 . 13968) (13970 . 14019) (14021 . 14069) (14071 . 22737) (22740 . 22748) (22750 . 22785) (22787 . 23999) (24002 . 24003) 24006 (24015 . 24017) 24026 (24028 . 24031) 24037 24039 24045 24049 (24052 . 24053) (24055 . 24056) 24059 (24071 . 24072) 24076 24078 24080 24082 24084 24087 24095 24101 24107 24111 24113 (24119 . 24122) (24125 . 24126) (24132 . 24134) (24137 . 24141) 24144 24147 24153 24156 24160 24165 24173 24182 (24204 . 24206) (24237 . 24238) ...) ((reply 31937 112364 116790 129755 136658 138039 138046 138140 138152 138154 140078 141715 141815 142320 144463 144477 144854 144895 145223 145280 145287 145350 145378 145856 146218 146252 146266 146632 146651 147011 147144 ... ... 147411 147424 147628 147669 147708 147817 147855 147868 147883 148031 148037 148064 148066 148071 ... 148149 ...) (tick 6 ... ... ... 91 ... 101 ... 212 267 30227 ... ... 31946 31954 32008 ... 32028 32040 ... ... 32066 32355 32363 32367 ... 32453 32457 32478 32571 32887 32945 32947 ... 32982 33053 33132 33211 33273 33313 33817 33897 ... 33920 33953 34487 34490 ... 35877 ...)) nil ((permanent-flags %Answered %Flagged %Deleted %Seen %Draft %*) (timestamp 20068 9319) (modseq . "509") (uidvalidity . "1313942954") (active 1 . 194638))) ((1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 ...) ((%Answered 31937 112364 116790 129755 136658 138039 138046 138140 138152 138154 140078 141715 141815 142320 144463 144477 144854 144895 145223 145280 145287 145350 145378 145856 146218 146252 146266 146632 146651 147011 147144 147360 147361 147401 147402 147411 147424 147628 147669 147708 147817 147855 147868 147883 148031 148037 148064 148066 148071 ...) (%Flagged 6 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 38 39 81 82 83 84 85 86 87 88 89 91 95 96 97 98 99 101 105 106 212 267 ...) (%Seen 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 ...)) 194642 1 194643 1 (%Answered %Flagged %Deleted %Seen %Draft %*) "1313942954" nil "512"))
  nnimap-update-infos((("[Gmail].All Mail" (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 ...) (... ... ...) 194642 1 194643 1 (%Answered %Flagged %Deleted %Seen %Draft %*) "1313942954" nil "512")) (("[Gmail].All Mail" 6 (... ... 948 ... ... ... ... ... ... ... ... ... ... 24006 ... 24026 ... 24037 24039 24045 24049 ... ... 24059 ... 24076 24078 24080 24082 24084 24087 24095 24101 24107 24111 24113 ... ... ... ... 24144 24147 24153 24156 24160 24165 24173 24182 ... ... ...) (... ...) nil (... ... ... ... ...))))
  nnimap-request-group("[Gmail].All Mail" "LocalIMAP" nil ("[Gmail].All Mail" 6 ((1 . 896) (898 . 945) 948 (950 . 961) (964 . 1774) (1776 . 13968) (13970 . 14019) (14021 . 14069) (14071 . 22737) (22740 . 22748) (22750 . 22785) (22787 . 23999) (24002 . 24003) 24006 (24015 . 24017) 24026 (24028 . 24031) 24037 24039 24045 24049 (24052 . 24053) (24055 . 24056) 24059 (24071 . 24072) 24076 24078 24080 24082 24084 24087 24095 24101 24107 24111 24113 (24119 . 24122) (24125 . 24126) (24132 . 24134) (24137 . 24141) 24144 24147 24153 24156 24160 24165 24173 24182 (24204 . 24206) (24237 . 24238) ...) ((reply 31937 112364 116790 129755 136658 138039 138046 138140 138152 138154 140078 141715 141815 142320 144463 144477 144854 144895 145223 145280 145287 145350 145378 145856 146218 146252 146266 146632 146651 147011 147144 ... ... 147411 147424 147628 147669 147708 147817 147855 147868 147883 148031 148037 148064 148066 148071 ... 148149 ...) (tick 6 ... ... ... 91 ... 101 ... 212 267 30227 ... ... 31946 31954 32008 ... 32028 32040 ... ... 32066 32355 32363 32367 ... 32453 32457 32478 32571 32887 32945 32947 ... 32982 33053 33132 33211 33273 33313 33817 33897 ... 33920 33953 34487 34490 ... 35877 ...)) nil ((permanent-flags %Answered %Flagged %Deleted %Seen %Draft %*) (timestamp 20068 9319) (modseq . "509") (uidvalidity . "1313942954") (active 1 . 194638))))
  gnus-activate-group("[Gmail].All Mail" scan)
  (let ((old ...) (old-high gnus-newsgroup-highest) (nnmail-fetched-sources ...) (new-active ...) i new) (unless new-active (error "Couldn't fetch new data")) (setq gnus-newsgroup-active (gnus-copy-sequence new-active)) (setq i (cdr gnus-newsgroup-active) gnus-newsgroup-highest i) (while (> i old-high) (push i new) (decf i)) (if (not new) (message "No gnus is bad news") (gnus-summary-insert-articles new) (setq gnus-newsgroup-unreads ...) (gnus-summary-limit ...)))
  gnus-summary-insert-new-articles()
  call-interactively(gnus-summary-insert-new-articles nil nil)

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Message #54 received at 9075 <at> debbugs.gnu.org (full text, mbox):

From: Dave Abrahams <dave <at> boostpro.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 9075 <at> debbugs.gnu.org
Subject: Re: expecting a list, got a vector
Date: Sun, 04 Sep 2011 17:43:21 -0800

[Message part 1 (text/plain, inline)]

on Sun Sep 04 2011, Dave Abrahams <dave-AT-boostpro.com> wrote:

> on Tue Aug 02 2011, Lars Ingebrigtsen <larsi-AT-gnus.org> wrote:
>
>> Dave Abrahams <dave <at> boostpro.com> writes:
>>
>>> It's fairly common when I do a `G' from the group buffer for
>>> everything to get stuck just after nnimap seems to have collected all
>>> its data from the server (I presume that's what's going on from the
>>> message about how many bytes have been read).
>>
>> Can you (setq debug-on-quit t) and see where it hangs?
>
> Here's another example:

Whoops, forgot to attach the contents of the *nnimap ...* buffer to that
one.  OMG, it's huge; I'm attaching an .xz archive instead.
In this one I was doing `/ N' from my "All Mail" group, BTW.

[nnimap-buffer.txt.xz (application/octet-stream, attachment)]

[Message part 3 (text/plain, inline)]

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Message #57 received at 9075 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Dave Abrahams <dave <at> boostpro.com>
Cc: 9075 <at> debbugs.gnu.org
Subject: Re: expecting a list, got a vector
Date: Sat, 10 Sep 2011 20:32:47 +0200

Dave Abrahams <dave <at> boostpro.com> writes:

>>> It's fairly common when I do a `G' from the group buffer for
>>> everything to get stuck just after nnimap seems to have collected all
>>> its data from the server (I presume that's what's going on from the
>>> message about how many bytes have been read).
>>
>> Can you (setq debug-on-quit t) and see where it hangs?
>
> Here's another example:
>
>   delq(16560 (897 946 947 949 962 963 1775 13969 14020 14070 16561
> 16562 16563 16564 16565 16566 16567 16568 16569 16570 16571 16572
> 16573 16574 16575 16576 16577 16578 16579 16580 16581 16582 16583
> 16584 16585 16586 16587 16588 16589 16590 16591 16592 16593 16594
> 16595 16596 16597 16598 16599 16600 ...))
>   (setq list1 (delq (car list2) list1))
>   (while list2 (setq list1 (delq ... list1)) (setq list2 (cdr list2)))

Hm.  Does Emacs hang forever here, or is it just very slow?  Is your
machine slow?  Your nnimap buffer was massively big, though, which seems
odd, too.  Does it always fetch and parse that much data if you `g'?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.