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

Previous Next

Full log

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

Previous Next

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