mime-layout part markers get mangled

Roger. I understand, though I haven't seen any instances of this
myself. It is a nasty bug!

Did you try it with different rvisions of VM? Why revision 1013?

Cheers,
Uday

I had seen it with previous revisions, though now I am not sure which
ones they were (I seem to remember maybe back at 8.1.92a). The only
reason for 1013 was that I had downloaded just to get the latest
development code. A quick grepping of the VM tree doesn't reveal
anything obvious, in fact there are very few places that vm uses the
mime-layout setting functions, which makes me more suspicious that it
is a markers issue. I wonder if in the mean time, it would be useful
to have a 'vm-mime-layout-use-cache' or such variable that, if set to
nil, could help sort out if its a performance killer.

-Arik

On Thu, Mar 24, 2011 at 5:13 AM, Uday Reddy <email address hidden> wrote:
> Roger.  I understand, though I haven't seen any instances of this
> myself.  It is a nasty bug!
>
> Did you try it with different rvisions of VM?  Why revision 1013?
>
> Cheers,
> Uday
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/740755
>
> Title:
>  mime-layout part markers get mangled
>
> Status in VM (View Mail) for Emacs:
>  New
>
> Bug description:
>  [VM development version at revision 1013]
>
>  After deleting and expunging (maybe) and (perhaps) saving, it seems
>  the markers that indicate buffer locations of mime parts all get set
>  to the same value (at about the start/end of the body or so) and thus
>  when decoding end up with no text in the presentation for any given
>  mime part.
>
>  The markers for the body start/end of the message in message-pointer
>  are still valid, and I can counteract the behavior by
>
>  (with-current-buffer "inbox" (vm-set-mime-layout-of (car vm-message-
>  pointer) (vm-mime-parse-entity-safe (car vm-message-pointer)))
>
>  This works since normally when previewing a message the layout is
>  retrieved from cache, and in the code above the parts are re-parsed
>  for their positions.
>
>  This bug is quite hard to track down since it doesn't always occur on
>  a delete/expunge. It may also be a bug in the handling of markers
>  after modifying the length of the buffer through deletes, and thus not
>  a VM issue, though I am suspicious because the markers for the message
>  itself are not affected and thus handled correctly. I have not yet
>  tested this with a emacs -q, perhaps others have seen this behavior.
>
>  An obvious solution is simply to freshly parse the mime parts
>  locations each time a message is previewed instead of caching this
>  information, but perhaps the caching is important for larger mails and
>  thus desirable (it takes essentially no time on my machine to do the
>  parsing for any emails I have tried).
>
>  And lastly, I have experienced this behavior both on an intel Mac osx
>  10.6 and a centos linux box.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/vm/+bug/740755/+subscribe
>

Hi Arik, I would prefer to track down the bug rather than to avoid
it. This might require some work both on your part and mine, and some
careful planning.

I think the thing to do is to create functions that check if the
layout data has been corrupted, and to repair it once it is found to
be corrupted. I will put this into a new branch based on revision 955
(which was the release 8.1.93a) and then you can merge it into your
own branch and use it in daily use.

I also notice that I may not have been exercising this bug because I
use headers-only IMAP folders. So, I will turn off the headers-only
operation so that I can exercise the bug.

Are you ok with the plan?

Cheers,
Uday

This sounds good. The checking for corruption may be difficult, but so far what I remember seeing is that the markers for layout elements all get set the the *same* point so this can be checked for and hopefully gets them all.

-Arik

Revision 1300 adds a debug test for cached MIME layouts. Further edits in rev. 1317 and 1339.

Hi Arik, after a long time, I got an instance of this situation. It was for an IMAP folder with external (headers-only) messages. I set vm-fetch-message-for-presentation to nil during some testing. And, this error happened. It seems to be due to some old code of Rob F., which I never understood why it was there.

However, you never mentioned IMAP or headers-only in your original bug report. So, I don't know if this instance had anything to do with what you observed.

Can you do a vm-submit-bug-report next time you get the error?

Cheers,
Uday

Hi Uday,

 > Hi Arik, after a long time, I got an instance of this situation. It was
 > for an IMAP folder with external (headers-only) messages. I set vm-
 > fetch-message-for-presentation to nil during some testing. And, this
 > error happened. It seems to be due to some old code of Rob F., which I
 > never understood why it was there.

Now that you mention it, I have not seen this bug in a very long time!
(am using 8.2.0b, with emacs 24.1.1) Pretty sure I was using an
emacs23 at the time.

 > However, you never mentioned IMAP or headers-only in your original bug
 > report. So, I don't know if this instance had anything to do with what
 > you observed.

For me, it was never related to IMAP or headers-only since I do not
use them. I could never really track down where it might have come
from, but I remember being suspicious of a more elaborate plot since
the markers were not modified within VM (I think...)

 >
 > Can you do a vm-submit-bug-report next time you get the error?
 >

If I ever see it pop up again, absolutely

Revision 1449 disables Rob F's code in vm-make-presentation-copy.

See Bug 1188241 for a related problem.