Subject: bug#9075: expecting a list, got a vector

From: Dave Abrahams <[email-masked]>
Date: Thu, 21 Jul 2011 19:33:39 -0400

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

> Dave Abrahams <[email-masked]> writes:
>
>> Debugger entered--Lisp error: (wrong-type-argument listp [32470 "Re:
>> gist gist: 973698" "tomprince
>> <[email-masked]>"
>> #("Mon, 16 May 2011 07:09:07 -0700" 0 1 (gnus-time (19921 12291)))
>> "<gist/973698/[email-masked]>" "<gist/[email-masked]>" 2039 18
>> nil ((Message-Id . "<gist/973698/[email-masked]>") (Message-ID
>> . "<gist/973698/[email-masked]>") (To . "[email-masked]"))])
>>   gnus-remove-thread("<[email-masked]>")
>>   gnus-rebuild-thread("<[email-masked]>" 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("<[email-masked]>")
>
> 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