Forward compatibility of cached data vectors

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

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

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

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.

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.

Fix committed to the trunk in rev. 1338.

Also fixed in 8.2.x branch, revision 1324.

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