VM

Forward compatibility of cached data vectors

Bug #916695 reported by mere user on 2012-01-15
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
VM
High
Uday Reddy
8.1.x
High
Uday Reddy

Bug Description

hi Uday, using the latest cvs version, when looking to my outgoing mail folder, I get this:

Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
  vm-follow-summary-cursor()
  vm-scroll-forward(nil)
  call-interactively(vm-scroll-forward nil nil)

let me know if you need a more detailed, reproducible report; I noticed that these abbreviated ones are typically sufficient for you to see what the problem is. :-)

I hope it's not just my settings...

Eli

Related branches

mere user writes:

> Public bug reported:
>
> hi Uday, using the latest cvs version, when looking to my outgoing mail
> folder, I get this:
>
> Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
> vm-follow-summary-cursor()
> vm-scroll-forward(nil)
> call-interactively(vm-scroll-forward nil nil)
>
> let me know if you need a more detailed, reproducible report; I noticed
> that these abbreviated ones are typically sufficient for you to see what
> the problem is. :-)

Not really. It might seem like I know what is happening already. That is
usually because I observed the same issue myself or because I made some
changes which I expect might have some funny effects like that.

In this case, we might need to sweat a bit because it is not an easy to problem
to track down. Summary problems are hard to figure out because they are
based on cached data. If for any reason the cached data becomes faulty, the
results are likely to show up in handling the summary. But the root
problems might have been somewhere else.

The first thing to do is to load the uncompiled version of the file that
gave the error. In this case, if you do

  C-h f vm-follow-summary-cursor

it tells you that it comes from vm-motion. So, if you

  M-x load-library RET vm-motion.el

we would get a better error trace.

The second thing to do would be to identify which revision introduced the
error. If you go to the vm build directory and do

  bzr log -l5

it shows the last 5 revisions. (Or, whichever number you specify.) Then if
you can think back and identify what was the last good revision you used,
that will give me some handle on where to look. In this case, the revision
1334 was a major revision, which added new fields to the cached data. So, I
am guessing that the revision 1333 might be good for you and 1334 might
break.

  bzr revert -rNNNN

backtracks your VM to an older revision NNNN.

Can you try those please? I will be going (coming?) to the US on Friday and
will be away from VM for at least a week. So, it will be good if we can
track this down today.

Cheers,
Uday

Download full text (3.3 KiB)

hi uday, so I used an older version of vm, and it complained bitterly
many times about cache data not being good somehow, but then when I
switched back to the development version, the error was gone. so I
must have again wasted your time. thanks for the propt response,
though! E

On Sun, Jan 15, 2012 at 12:53 PM, Uday Reddy <email address hidden> wrote:
> mere user writes:
>
>> Public bug reported:
>>
>> hi Uday, using the latest cvs version, when looking to my outgoing mail
>> folder, I get this:
>>
>> Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
>>   vm-follow-summary-cursor()
>>   vm-scroll-forward(nil)
>>   call-interactively(vm-scroll-forward nil nil)
>>
>> let me know if you need a more detailed, reproducible report; I noticed
>> that these abbreviated ones are typically sufficient for you to see what
>> the problem is.  :-)
>
> Not really.  It might seem like I know what is happening already.  That is
> usually because I observed the same issue myself or because I made some
> changes which I expect might have some funny effects like that.
>
> In this case, we might need to sweat a bit because it is not an easy to problem
> to track down.  Summary problems are hard to figure out because they are
> based on cached data.  If for any reason the cached data becomes faulty, the
> results are likely to show up in handling the summary.  But the root
> problems might have been somewhere else.
>
> The first thing to do is to load the uncompiled version of the file that
> gave the error.  In this case, if you do
>
>  C-h f vm-follow-summary-cursor
>
> it tells you that it comes from vm-motion.  So, if you
>
>  M-x load-library RET vm-motion.el
>
> we would get a better error trace.
>
> The second thing to do would be to identify which revision introduced the
> error.  If you go to the vm build directory and do
>
>  bzr log -l5
>
> it shows the last 5 revisions.  (Or, whichever number you specify.)  Then if
> you can think back and identify what was the last good revision you used,
> that will give me some handle on where to look.  In this case, the revision
> 1334 was a major revision, which added new fields to the cached data.  So, I
> am guessing that the revision 1333 might be good for you and 1334 might
> break.
>
>  bzr revert -rNNNN
>
> backtracks your VM to an older revision NNNN.
>
> Can you try those please?  I will be going (coming?) to the US on Friday and
> will be away from VM for at least a week.  So, it will be good if we can
> track this down today.
>
> Cheers,
> Uday
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/916695
>
> Title:
>   vm-follow-summary-cursor
>
> Status in VM (View Mail) for Emacs:
>  New
>
> Bug description:
>  hi Uday, using the latest cvs version, when looking to my outgoing
>  mail folder, I get this:
>
>  Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
>    vm-follow-summary-cursor()
>    vm-scroll-forward(nil)
>    call-interactively(vm-scroll-forward nil nil)
>
>  let me know if you need a more detailed, reproducible report; I
>  noticed that these abbreviated ones are typically sufficient ...

Read more...

Uday Reddy (reddyuday) wrote :

mere user writes:

> hi uday, so I used an older version of vm, and it complained bitterly
> many times about cache data not being good somehow, but then when I
> switched back to the development version, the error was gone. so I
> must have again wasted your time. thanks for the propt response,
> though! E

Hmm. That was unexpected! The old version is supposed to have worked with
the new data as if it is normal. That is a bug you have uncovered!

In any case, when it thought that you had bad cached data, it reset it to
blank data. So, whatever problems there might have been in the cached data,
are now gone. We are lucky that nothing got lost in the process.

Cheers,
Uday

Uday Reddy (reddyuday) on 2012-01-15
Changed in vm:
status: New → Triaged
importance: Undecided → High
assignee: nobody → Uday Reddy (reddyuday)
milestone: none → 8.2.90a
summary: - vm-follow-summary-cursor
+ Forward compatibility of cached data vectors
Uday Reddy (reddyuday) on 2012-02-02
Changed in vm:
milestone: 8.2.90a → 8.2.89a
Uday Reddy (reddyuday) wrote :

Notes:

Both VM 8.2.0a and 8.2.0b are unable to deal with extended cached-data-vector. They declare "Bad VM cache data" and reset it to nil. This should not happen. Something is wrong.

Uday Reddy (reddyuday) wrote :

Notes:

In fact, the problem was introduced in rev. 611, and VM releases 8.1.0 and 8.1.1 suffer from the problem as well. This means that it is imperative that a bug fix release 8.1.2 is necessary.

Uday Reddy (reddyuday) wrote :

Fix committed to the trunk in rev. 1338.

Changed in vm:
status: Triaged → Fix Committed
Uday Reddy (reddyuday) on 2012-03-05
no longer affects: vm/8.2.x
Changed in vm:
milestone: 8.2.89a → 8.2.0b1
Uday Reddy (reddyuday) on 2012-11-11
Changed in vm:
status: Fix Committed → Fix Released
Uday Reddy (reddyuday) on 2015-11-05
Changed in vm:
milestone: 8.2.1a → 8.2.0
Uday Reddy (reddyuday) wrote :

Also fixed in 8.2.x branch, revision 1324.

Changed in vm:
milestone: 8.2.1a → 8.2.0
Uday Reddy (reddyuday) on 2016-10-30
tags: added: 8.0 cachedata
Changed in vm:
status: Fix Released → Fix Committed
Uday Reddy (reddyuday) wrote :

More fixes in rev. 1512 of trunk. Needs to be patched into 8.1.x and 8.2.x branches.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers