notmuch-emacs bug report -- infinite looping trying to select next message

notmuch-emacs bug report -- infinite looping trying to select next message

[Michael Hudson-Doyle]

[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]

The attached gzipped mbox appears to trip up the emacs interface.  The
problem seems to come from the message with id
CAGNsrLCWv6=36q+q+5Hc_SzgdZ2ergeKkapT7T3xXvim=2cK+A@mail.gmail.com.

If you load up the thread in emacs, you get a message:

mm-extern-cache-contents: Couldn't find access type

Then attempting to advance past the last display message (or pressing A,
or a few other things I expect gets emacs to loop indefinitely.
toggle-debug-on-quit gets me this backtrace:

Debugger entered--Lisp error: (quit)
  notmuch-show-message-extent()
  notmuch-show-message-bottom()
  notmuch-show-move-to-message-bottom()
  notmuch-show-goto-message-next()
  notmuch-show-next-open-message(nil)
  call-interactively(notmuch-show-next-open-message nil nil)

Looking at the suspect message one sees this:

--20cf305b0f1a1caaf604b875ea95
Content-Type: message/external-body; access-type=x-mutt-deleted;
        expiration="Wed, 8 Feb 2012 08:45:08 -0800"; length=644023

Content-Type: text/x-log; charset=US-ASCII; name="binary.log"
Content-Disposition: attachment; filename="binary.log"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gyejghyz0


--20cf305b0f1a1caaf604b875ea95
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

which looks a bit odd to me (maybe mailman stripped an attachment), but
I don't know much about MIME :-)

Cheers,
mwh


[-- Attachment #2: notmuch-el-hang.mbox.gz --]
[-- Type: application/octet-stream, Size: 25936 bytes --]

Re: notmuch-emacs bug report -- infinite looping trying to select next message

[Rodney Lorrimar]

Hi Michael,

On Tue, 14 Feb 2012 11:01:56 +1300, Michael Hudson-Doyle <michael.hudson@canonical.com> wrote:
> The attached gzipped mbox appears to trip up the emacs interface.  The
> problem seems to come from the message with id
> CAGNsrLCWv6=36q+q+5Hc_SzgdZ2ergeKkapT7T3xXvim=2cK+A@mail.gmail.com.
> 
> If you load up the thread in emacs, you get a message:
> 
> mm-extern-cache-contents: Couldn't find access type

If you put (require 'gnus-art) into your .emacs and eval it, does the
problem go away?

I had a similar problem when running a newer emacs-snapshot with
notmuch. See this thread: id:"87d3aaqyur.fsf@eve.chaoflow.net"

> Then attempting to advance past the last display message (or pressing A,
> or a few other things I expect gets emacs to loop indefinitely.
> toggle-debug-on-quit gets me this backtrace:

I believe the actual bug is in gnus but I don't really like the loop on
error behaviour of notmuch. I would like to try and fix it but haven't
found the time.


Cheers,

Rodney

Re: notmuch-emacs bug report -- infinite looping trying to select next message

[Michael Hudson-Doyle]

Thanks for the reply!

On Tue, 14 Feb 2012 10:41:20 +0100, Rodney Lorrimar <dev@rodney.id.au> wrote:
> Hi Michael,
> 
> On Tue, 14 Feb 2012 11:01:56 +1300, Michael Hudson-Doyle <michael.hudson@canonical.com> wrote:
> > The attached gzipped mbox appears to trip up the emacs interface.  The
> > problem seems to come from the message with id
> > CAGNsrLCWv6=36q+q+5Hc_SzgdZ2ergeKkapT7T3xXvim=2cK+A@mail.gmail.com.
> > 
> > If you load up the thread in emacs, you get a message:
> > 
> > mm-extern-cache-contents: Couldn't find access type
> 
> If you put (require 'gnus-art) into your .emacs and eval it, does the
> problem go away?

No.

> I had a similar problem when running a newer emacs-snapshot with
> notmuch. See this thread: id:"87d3aaqyur.fsf@eve.chaoflow.net"

I'm running emacs-snapshot-gtk from Ubuntu Oneiric, emacs-version says

GNU Emacs 23.3.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.5) of 2011-08-15 on allspice, modified by Debian

> > Then attempting to advance past the last display message (or pressing A,
> > or a few other things I expect gets emacs to loop indefinitely.
> > toggle-debug-on-quit gets me this backtrace:
> 
> I believe the actual bug is in gnus but I don't really like the loop on
> error behaviour of notmuch. I would like to try and fix it but haven't
> found the time.

As far as I can tell, gnus isn't involved here.  I may be wrong, of
course!

Cheers,
mwh

Re: notmuch-emacs bug report -- infinite looping trying to select next message

[Rodney Lorrimar]

Hi Michael,

On Wed, 15 Feb 2012 10:57:42 +1300, Michael Hudson-Doyle <michael.hudson@canonical.com> wrote:
> Thanks for the reply!
> 
> On Tue, 14 Feb 2012 10:41:20 +0100, Rodney Lorrimar <dev@rodney.id.au> wrote:
> > Hi Michael,
> > 
> > On Tue, 14 Feb 2012 11:01:56 +1300, Michael Hudson-Doyle <michael.hudson@canonical.com> wrote:
> > > The attached gzipped mbox appears to trip up the emacs interface.  The
> > > problem seems to come from the message with id
> > > CAGNsrLCWv6=36q+q+5Hc_SzgdZ2ergeKkapT7T3xXvim=2cK+A@mail.gmail.com.
> > > 
> > > If you load up the thread in emacs, you get a message:
> > > 
> > > mm-extern-cache-contents: Couldn't find access type
> > 
> > If you put (require 'gnus-art) into your .emacs and eval it, does the
> > problem go away?
> 
> No.

Oh well.

I loaded up the thread in notmuch and also got an infinite loop.

> > > Then attempting to advance past the last display message (or pressing A,
> > > or a few other things I expect gets emacs to loop indefinitely.
> > > toggle-debug-on-quit gets me this backtrace:
> > 
> > I believe the actual bug is in gnus but I don't really like the loop on
> > error behaviour of notmuch. I would like to try and fix it but haven't
> > found the time.
> 
> As far as I can tell, gnus isn't involved here.  I may be wrong, of
> course!

After setting a breakpoint in mm-extern-cache-contents I'm inclined to
agree, but I'm not really sure.

The following hack to 0.11 works around the problem. I think the experts
here would be able to come up with something better.

Cheers,

Rodney

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 82d11c9..48c15d2 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -327,7 +327,8 @@ current buffer, if possible."
     (with-temp-buffer
       (let ((handle (mm-make-handle (current-buffer) (list content-type))))
    (if (and (mm-inlinable-p handle)
-        (mm-inlined-p handle))
+        (mm-inlined-p handle)
+        (cdr (mm-handle-type handle)))
        (let ((content (notmuch-show-get-bodypart-content msg part nth)))
          (insert content)
          (set-buffer display-buffer)

Re: notmuch-emacs bug report -- infinite looping trying to select next message

[David Bremner]

Michael Hudson-Doyle <michael.hudson@canonical.com> writes:

> The attached gzipped mbox appears to trip up the emacs interface.  The
> problem seems to come from the message with id
> CAGNsrLCWv6=36q+q+5Hc_SzgdZ2ergeKkapT7T3xXvim=2cK+A@mail.gmail.com.
>

I can't reproduce this bug in current git, so I'm going to assume
something fixed it in the intervening years. In particular our handling
of error reporting for corrupted parts changed, so maybe that was it.

Thanks so much for including a test case with your bug report,

d

Re: notmuch-emacs bug report -- infinite looping trying to select next message

[Michael Hudson-Doyle]

David Bremner <david@tethera.net> writes:

> Michael Hudson-Doyle <michael.hudson@canonical.com> writes:
>
>> The attached gzipped mbox appears to trip up the emacs interface.  The
>> problem seems to come from the message with id
>> CAGNsrLCWv6=36q+q+5Hc_SzgdZ2ergeKkapT7T3xXvim=2cK+A@mail.gmail.com.
>>
>
> I can't reproduce this bug in current git, so I'm going to assume
> something fixed it in the intervening years.

I find the same.

> In particular our handling of error reporting for corrupted parts
> changed, so maybe that was it.

When I load up the thread that caused the problem I end up with this in
the buffer:

         [ message/external-body ]
         !!! Bodypart insert error: Couldn't find access type !!!
         [ text/plain ]

so I think it's pretty likely your guess is accurate.

> Thanks so much for including a test case with your bug report,

No problem, thanks for checking this ancient report!  (And thanks to
myself for including the message-id in the report...)

Cheers,
mwh