Re: bug: "no top level messages" crash on Zen email loops

[David Bremner]

Antoine Beaupré  writes:

> Hi!
>
> Here's a fun bug for you Xapian tricksters.
>
> Two emails attached make notmuch crash when trying to display the
> folder.
>
> $ notmuch show thread:0001
> Internal error: Thread 0001 has no toplevel messages.
>  (notmuch-show.c:1012)

this bug should be fixed in notmuch 0.26.2

d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: bug: "no top level messages" crash on Zen email loops

[Olly Betts]

On Thu, Mar 29, 2018 at 08:50:22AM -0400, Antoine Beaupré wrote:
> On 2018-03-29 04:17:21, Olly Betts wrote:
> > If changes to a new database which didn't modify the termlist table were
> > committed, then a disk block which had been allocated to be the root
> > block in the termlist table was leaked (not used but not on the
> > freelist of blocks the table can recycle).  This was largely harmless,
> > except that it was detected by Database::check() and caused an error.
> 
> Hmm... but if I understand correctly, that's one part of the story: I
> could get that error and not have the problem with `notmuch show`. Does
> that *also* resolve the issue with email loops?

Yes, from what bremner said on IRC there's still a notmuch bug here.

My reply was really just in the context of Xapian to note what the bug
actually was and when the fix would appear (since bremner sent his
message to both the notmuch and Xapian lists).

Cheers,
Olly
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: bug: "no top level messages" crash on Zen email loops

[David Bremner]

Antoine Beaupré  writes:

> Hmm... but if I understand correctly, that's one part of the story: I
> could get that error and not have the problem with `notmuch show`. Does
> that *also* resolve the issue with email loops?

I don't think so, no.

d


___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: bug: "no top level messages" crash on Zen email loops

[Antoine Beaupré]

On 2018-03-29 04:17:21, Olly Betts wrote:
> On Mon, Mar 19, 2018 at 05:03:21PM -0300, David Bremner wrote:
>> I can confirm this reproduces both the xapian-check and the notmuch-show
>> error. Olly agrees that whatever notmuch is doing wrong, it shouldn't
>> lead to a corrupted database
>
> There was a Xapian bug here, which I fixed on master last week and will
> be fixed in 1.4.6.

An honor. It's not every day you find a bug in a database software. ;)

> If changes to a new database which didn't modify the termlist table were
> committed, then a disk block which had been allocated to be the root
> block in the termlist table was leaked (not used but not on the
> freelist of blocks the table can recycle).  This was largely harmless,
> except that it was detected by Database::check() and caused an error.

Hmm... but if I understand correctly, that's one part of the story: I
could get that error and not have the problem with `notmuch show`. Does
that *also* resolve the issue with email loops?

A.

-- 
Travail, du latin Tri Palium trois pieux, instrument de torture.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: bug: "no top level messages" crash on Zen email loops

[Olly Betts]

On Mon, Mar 19, 2018 at 05:03:21PM -0300, David Bremner wrote:
> I can confirm this reproduces both the xapian-check and the notmuch-show
> error. Olly agrees that whatever notmuch is doing wrong, it shouldn't
> lead to a corrupted database

There was a Xapian bug here, which I fixed on master last week and will
be fixed in 1.4.6.

If changes to a new database which didn't modify the termlist table were
committed, then a disk block which had been allocated to be the root
block in the termlist table was leaked (not used but not on the
freelist of blocks the table can recycle).  This was largely harmless,
except that it was detected by Database::check() and caused an error.

Cheers,
Olly
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: bug: "no top level messages" crash on Zen email loops

[David Bremner]

Antoine Beaupré  writes:

> On 2018-03-19 13:36:49, David Bremner wrote:
>>
>> I can't duplicate that part.  
>
> That's very strange. I can reproduce this on my workstation here, but
> taking the tarball I sent in the original message, I can't reproduce
> anymore. So something changed! I suspect it's the "flags" on the
> message. I have "F" everywhere because I'm experimenting with syncing
> (badly) my inbox tag everywhere, through the flagged tag. All post-new
> hooks stuff that shouldn't affect this because it's in a new
> environment, but it does change the flag on the files sometimes.
>
> So attached is a *new* reproducer, with which I *can* reproduce in a
> clean VM with notmuch from stretch (0.23?).

I can confirm this reproduces both the xapian-check and the notmuch-show
error. Olly agrees that whatever notmuch is doing wrong, it shouldn't
lead to a corrupted database (unless we reach around the API and access
files directly, which I don't think we do).

d






___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: bug: "no top level messages" crash on Zen email loops

[Antoine Beaupré]

And obviously I forget the frigging attachment.



zendesk-email-loop2.tgz
Description: application/gtar-compressed

PS: don't we have a "you forgot to actually attach the damn file" plugin
when we detect the word "attachment" and there's no attach? :p
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: bug: "no top level messages" crash on Zen email loops

[Antoine Beaupré]

On 2018-03-19 13:36:49, David Bremner wrote:
> Antoine Beaupré  writes:
>
>> Hi!
>>
>> Here's a fun bug for you Xapian tricksters.
>>
>> Two emails attached make notmuch crash when trying to display the
>> folder.
>>
>> $ notmuch show thread:0001
>> Internal error: Thread 0001 has no toplevel messages.
>>  (notmuch-show.c:1012)
>>
>> Those are the two messages:
>>
>> $ notmuch search --output messages  thread:0001
>> id:9379qm5z39_5aa86b134fcfb_174033fc97a2cb98c7198d_sp...@zendesk.com
>> id:9379qm5z39_5aa86b1350504_174eb3fc97a2cb98c71674_sp...@zendesk.com
>>
>> `notmuch show` on either messages crashes the same way:
>>
>> $ notmuch show 
>> id:9379qm5z39_5aa86b1350504_174eb3fc97a2cb98c71674_sp...@zendesk.com
>> Internal error: Thread 0001 has no toplevel messages.
>>  (notmuch-show.c:1012)
>
> I can't duplicate that part.  

That's very strange. I can reproduce this on my workstation here, but
taking the tarball I sent in the original message, I can't reproduce
anymore. So something changed! I suspect it's the "flags" on the
message. I have "F" everywhere because I'm experimenting with syncing
(badly) my inbox tag everywhere, through the flagged tag. All post-new
hooks stuff that shouldn't affect this because it's in a new
environment, but it does change the flag on the files sometimes.

So attached is a *new* reproducer, with which I *can* reproduce in a
clean VM with notmuch from stretch (0.23?).

To reproduce, with a `debian/stretch64` vagrant VM:

host$ vagrant init debian/stretch64 && vagrant up && vagrant ssh
guest$ sudo apt install notmuch
guest$ notmuch setup # pick all defaults
guest$ wget $url_of_the_reproducer
guest$ tar zxfv zendesk-mail-loop2.tgz
guest$ mv gitlab mail # to put it where notmuch expects
guest$ notmuch new
guest$ notmuch show thread:0001
Internal error: Thread 0001 has no toplevel messages.
 (notmuch-show.c:957)

I can reproduce this reproducibly here now.

Phew, that is definitely weird! For what it's worth, here's the diff
between the two tarballs:

[429]anarcat@curie:~1$ diffoscope zendesk-email-loop.tgz zendesk-email-loop2.tgz
 
||
  100% Time: 0:00:00 
--- zendesk-email-loop.tgz
+++ zendesk-email-loop2.tgz
├── metadata
│ @@ -1 +1 @@
│ -gzip compressed data, last modified: Mon Mar 19 13:21:40 2018, from Unix
│ +gzip compressed data, last modified: Mon Mar 19 17:38:29 2018, from Unix
│   --- zendesk-email-loop.tgz-content
├── +++ zendesk-email-loop2.tgz-content
├── file list
│ │ @@ -1,5 +1,5 @@
│ │ -drwx--   0 anarcat   (1000) anarcat   (1000)0 2018-03-19 
13:11:45.00 gitlab/cur/
│ │ --rw---   0 anarcat   (1000) anarcat   (1000) 8858 2018-03-14 
00:27:37.00 gitlab/cur/1521465105.R3423354954039434325.curie:2,FS
│ │ --rw---   0 anarcat   (1000) anarcat   (1000)11861 2018-03-19 
08:50:10.00 gitlab/cur/1521464914.R16228666356894086807.curie:2,F
│ │ +drwx--   0 anarcat   (1000) anarcat   (1000)0 2018-03-19 
17:35:32.00 gitlab/cur/
│ │ +-rw---   0 anarcat   (1000) anarcat   (1000) 8858 2018-03-14 
00:27:37.00 gitlab/cur/1521463753.R9368947314807690338.curie:2,FS
│ │ +-rw---   0 anarcat   (1000) anarcat   (1000) 8720 2018-03-14 
00:30:59.00 gitlab/cur/1521463752.R13151765805797588408.curie:2,FS
│ │  drwx--   0 anarcat   (1000) anarcat   (1000)0 2018-03-19 
12:49:12.00 gitlab/new/
│ │ -drwx--   0 anarcat   (1000) anarcat   (1000)0 2018-03-19 
13:11:45.00 gitlab/tmp/
│ │ +drwx--   0 anarcat   (1000) anarcat   (1000)0 2018-03-19 
12:49:13.00 gitlab/tmp/
│   --- gitlab/cur/1521465105.R3423354954039434325.curie:2,FS
├── +++ gitlab/cur/1521463753.R9368947314807690338.curie:2,FS

ie. the files are identical, but the serial numbers, timestamps and
flags differ. Maybe this makes the directory ordering (so the load order
in notmuch new) differ? No idea.

But hopefully this will allow you to reproduce more reliably.

A.

-- 
La seule excuse de Dieu, c'est qu'il n'existe pas.
- Stendhal
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: bug: "no top level messages" crash on Zen email loops

[David Bremner]

Antoine Beaupré  writes:

> Hi!
>
> Here's a fun bug for you Xapian tricksters.
>
> Two emails attached make notmuch crash when trying to display the
> folder.
>
> $ notmuch show thread:0001
> Internal error: Thread 0001 has no toplevel messages.
>  (notmuch-show.c:1012)
>
> Those are the two messages:
>
> $ notmuch search --output messages  thread:0001
> id:9379qm5z39_5aa86b134fcfb_174033fc97a2cb98c7198d_sp...@zendesk.com
> id:9379qm5z39_5aa86b1350504_174eb3fc97a2cb98c71674_sp...@zendesk.com
>
> `notmuch show` on either messages crashes the same way:
>
> $ notmuch show 
> id:9379qm5z39_5aa86b1350504_174eb3fc97a2cb98c71674_sp...@zendesk.com
> Internal error: Thread 0001 has no toplevel messages.
>  (notmuch-show.c:1012)

I can't duplicate that part.  

>
> Note that displaying the messages weith `--format raw` doesn't crash, so
> it's really the thread structure that's broken. Obviously, emacs can't
> display the messages either and doesn't touch the unread tags when
> trying to load the message, which is to be expected I guess.
>
> Xapian is also unhappy with the database created by notmuch new:
>
> $ xapian-check gitlab/.notmuch/xapian/
> docdata:
> blocksize=8K items=1 firstunused=1 revision=7 levels=0 root=0
> B-tree checked okay
> docdata table structure checked OK
>
> termlist:
> blocksize=8K items=12 firstunused=4 revision=7 levels=0 root=3
> xapian-check: DatabaseError: 1 unused block(s) missing from the free list, 
> first is 0

Surprisingly (to me), I can duplicate that, so that's something to
pursue.

d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

bug: "no top level messages" crash on Zen email loops

[Antoine Beaupré]

Hi!

Here's a fun bug for you Xapian tricksters.

Two emails attached make notmuch crash when trying to display the
folder.

$ notmuch show thread:0001
Internal error: Thread 0001 has no toplevel messages.
 (notmuch-show.c:1012)

Those are the two messages:

$ notmuch search --output messages  thread:0001
id:9379qm5z39_5aa86b134fcfb_174033fc97a2cb98c7198d_sp...@zendesk.com
id:9379qm5z39_5aa86b1350504_174eb3fc97a2cb98c71674_sp...@zendesk.com

`notmuch show` on either messages crashes the same way:

$ notmuch show 
id:9379qm5z39_5aa86b1350504_174eb3fc97a2cb98c71674_sp...@zendesk.com
Internal error: Thread 0001 has no toplevel messages.
 (notmuch-show.c:1012)

Note that displaying the messages weith `--format raw` doesn't crash, so
it's really the thread structure that's broken. Obviously, emacs can't
display the messages either and doesn't touch the unread tags when
trying to load the message, which is to be expected I guess.

Xapian is also unhappy with the database created by notmuch new:

$ xapian-check gitlab/.notmuch/xapian/
docdata:
blocksize=8K items=1 firstunused=1 revision=7 levels=0 root=0
B-tree checked okay
docdata table structure checked OK

termlist:
blocksize=8K items=12 firstunused=4 revision=7 levels=0 root=3
xapian-check: DatabaseError: 1 unused block(s) missing from the free list, 
first is 0

Valgrind is not particularly unhappy with notmuch, so it doesn't seem
like a memory error:

==26723== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

I tried to track this down in gdb, i got as far as finding that, in
`notmuch_thread_get_toplevel_messages`, the `list` object is corrupt (?)
already (`list->head == NULL`) which obviously makes it hard to, er,
list messages in a thread. :p I lost the exact backtrace and so on, but
I'm not sure there's much we can get from gdb: it seems the problem
might be in notmuch-new, but I'm a little out of my depth to debug
*that* without any further pointers.

This is with 0.26-1~bpo9+1 on Debian stretch, but I can also reproduce
with 0.23 on another Debian stretch machine, using a similar mail
spool.

My guess is that those messages are somewhat special: notice how the
reply-to identifiers *loop* between the two messages?

Message one:

Message-ID: <9379qm5z39_5aa86b134fcfb_174033fc97a2cb98c7198d_sp...@zendesk.com>
In-Reply-To: <9379qm5...@zendesk.com>
 <9379qm5z39_5aa86b1350504_174eb3fc97a2cb98c71674_sp...@zendesk.com>

Message two:

Message-ID: <9379qm5z39_5aa86b1350504_174eb3fc97a2cb98c71674_sp...@zendesk.com>
In-Reply-To: <9379qm5...@zendesk.com>
 <9379qm5z39_5aa86b134fcfb_174033fc97a2cb98c7198d_sp...@zendesk.com>

And indeed, a mailbox with only *one* of those messages doesn't cause
the crash. But also: the original thread is now made of *three*
messages, and taking any one of the two messages above with that *third*
message doesn't cause the crash:

Message three:

Message-ID: <9379qm5z39_5aaf79c126a_94233ffb30ecb9982187c0_sp...@zendesk.com>
In-Reply-To: <9379qm5...@zendesk.com>
 <9379qm5z39_5aa86b1350504_174eb3fc97a2cb98c71674_sp...@zendesk.com>

This message also shows correctly threaded with message two if present,
otherwise the thread is (obviously) broken with only message one and
three.

Mutt displays those messages as a "normal" three-level thread:

   1   ! mar 14 GitLab Support  (4,7K) Your GitLab support request has been 
received
   2   ! mar 14 GitLab Support  (4,5K) └>comments not showing up?
   3 O ! mar 19 XXX (7,9K)  └>[GitLab, Inc.] Re: comments not 
showing up?

The numbers on the left (1, 2, 3) correspond to the labeling I used
above as well (one, two, three).

The third message is not included here because it's an actual reply from
a human from GitLab (yay gitlab! :) which I'd need approval before
sharing here. The first message is an automated response so I thought it
was fair game to share publicly. The second is a copy of my own message
which triggered the autoreply, which is probably the source of the
loop. The software generating this mess is Zendesk.com. I haven't had
that problem with other interactions with Zendesk, maybe because I
never talked with a Zendesk that sent autoreplies.

To reproduce this, untar the attachment anywhere (say $HOME) and then
hack a notmuch config file pointing there, e.g.:

$ diff .notmuch-config*
15c15
< path=/home/anarcat/Maildir/
---
> path=/home/anarcat/gitlab/

Then point notmuch to that config (export
NOTMUCH_CONFIG=~/.notmuch-config-test) and run notmuch new (which should
find only two messages). Then run the commands from the above of this
email, of course. :)

Thanks for any input,

A.

PS: I must say I am grateful and impressed by the reliability of
notmuch. I've been using notmuch for *years* now and it's the *first*
time, for as long as I remember, that I had to go back to mutt to read
email. So kudos to the team, good job. :)

-- 
Si les élections n'étaient pas indispensables à la prospérité du
capital, on ne nous