VM

mime-layout part markers get mangled

Bug #740755 reported by Arik
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
VM
In Progress
Medium
Uday Reddy

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.

Tags: mime

Related branches

Revision history for this message
Uday Reddy (reddyuday) wrote : Re: [Bug 740755] [NEW] 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

Revision history for this message
Arik (akwm) wrote :

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
>

Revision history for this message
Uday Reddy (reddyuday) wrote :

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

Uday Reddy (reddyuday)
Changed in vm:
status: New → Triaged
importance: Undecided → High
assignee: nobody → Uday Reddy (reddyuday)
milestone: none → 8.2.0
Revision history for this message
Arik (akwm) wrote :

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

Uday Reddy (reddyuday)
tags: added: mime
Uday Reddy (reddyuday)
Changed in vm:
status: Triaged → In Progress
importance: High → Low
milestone: 8.2.0 → 8.2.1
Uday Reddy (reddyuday)
Changed in vm:
importance: Low → Medium
Revision history for this message
Uday Reddy (reddyuday) wrote :

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

Revision history for this message
Uday Reddy (reddyuday) wrote :

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

Revision history for this message
Arik (akwm) wrote : [Bug 740755] Re: mime-layout part markers get mangled

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 history for this message
Uday Reddy (reddyuday) wrote :

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

Revision history for this message
Uday Reddy (reddyuday) wrote :

See Bug 1188241 for a related problem.

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.