GNU bug report logs - #9136
Random backtrace from gnus-article-stop-animations

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 9136 in the body.
You can then email your comments to 9136 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: david.goldberg6 <at> verizon.net (Dave Goldberg)
To: submit <at> debbugs.gnu.org (The Gnus Bugfixing Girls + Boys)
Subject: Random backtrace from gnus-article-stop-animations
Date: Wed, 20 Jul 2011 23:52:02 -0400

Since doing a git pull last week, after three weeks vacation during
which I did not do any updates (so roughly somewhere between 20 June
and 11 July; I am pretty sure that I noticed
gnus-article-stop-animations listed as new in the changelog in that
timeframe) I sometimes get into a situation in which attempting to
open any article results in this backtrace:

Debugger entered--Lisp error: (wrong-type-argument arrayp ("run-at-time<5>" 1 1 article-update-date-lapsed nil t nil (0 0 0)))
  gnus-article-stop-animations()
  gnus-article-setup-buffer()
  gnus-article-prepare(112249 nil)
  gnus-summary-display-article(112249 nil)
  gnus-summary-select-article(nil force)
  gnus-summary-show-article(nil)
  call-interactively(gnus-summary-show-article)

The only recourse is to kill xemacs and start over.  I cannot figure
out what triggers it.  I may go a day or two without experiencing it
at all and then, like today, have it hit me three times in a couple
hours.

Sometimes the argument in the backtrace refers to a different timer,
such as the one that determines how long to cache my certificate
passphrase.

No Gnus v0.18
XEmacs 21.4 (patch 22) "Instant Classic" [Lucid] (x86_64-unknown-linux, Mule) of Wed Sep  9 2009 on davestoy

Thanks,
-- 
Dave Goldberg
david.goldberg6 <at> verizon.net

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

From: david.goldberg6 <at> verizon.net (Dave Goldberg)
To: 9136 <at> debbugs.gnu.org
Subject: Re: Random backtrace from gnus-article-stop-animations
Date: Wed, 27 Jul 2011 22:51:44 -0400

I've run gnus-article-stop-animations under edebug and have discovered new information.  Normally timer-list is unbound from the time I start gnus.  Something in my processing is causing it to be aliased to itimer-list which is not an array and results in the function erroring out.  The only place I see that aliasing taking place is in timer.el (part of the fsf-compat package), but I cannot figure out what might be causing it to be loaded; ordinarily it's not.  Certainly it seems no part of gnus is doing it; pgg might be a possibility I've never found it loaded as I use epg.  Is there a debug or trace capability that would result in all file loads being recorded in the message log?

Thanks,
-- 
Dave Goldberg
david.goldberg6 <at> verizon.net

Message #13 received at 9136-close <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: david.goldberg6 <at> verizon.net (Dave Goldberg)
Cc: 9136-close <at> debbugs.gnu.org, bugs <at> gnus.org
Subject: Re: bug#9136: Random backtrace from gnus-article-stop-animations
Date: Sun, 31 Jul 2011 18:39:51 +0200

david.goldberg6 <at> verizon.net (Dave Goldberg) writes:

> I've run gnus-article-stop-animations under edebug and have discovered
> new information.

This was fixed earlier today by a patch from Marcus Harnisch.

-- 
(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.