On Fri, 2009-08-14 at 16:38 +1000, Phillip Macey wrote:
Maybe I can narrow it down to a particular email and then we can take it from there.
Yeah, that would be good.
- It seems to be an attribute of the destination folder. I can successfully move the mail into a new (empty) folder. As soon as I try to move into that specific destination, it starts crashing.
It's most likely because of the caching decisions. You can use idxview to get a list of them, e.g.
idxview ~/Maildir/.dest ..
-- Cache fields -- # Name Type Size Dec Last used 0: flags bit 4 tmp 2009-08-13 12:20 1: date.sent fix 8 tmp 2009-08-07 18:22 2: date.received fix 4 yes 2009-08-13 14:51 .. 8: hdr.FROM hdr - tmp 2009-08-13 18:37 ..
If you duplicate the caching decisions, or at least add some caching decisions, that might be enough to cause it to crash. You can add those decisions simply by fetching that data. For example:
1 select mailbox 2 fetch 1 (body.peek[header.fields (from to)] bodystructure internaldate)
- The other thing that I think is a pattern - using thunderbird, if I select all the emails in the folder (eg Ctrl-A) and try to move them - it crashes. If I hand select a smaller subset of the emails, they tend to move successfully. The smaller the number the more likely it would be successful. I tried to figure out if there was a point at which it stopped working - but it seemed like the number kept on getting smaller as I kept trying. By the end, I was not even able to move a single email without getting a crash
Sounds like when destination mailbox got larger it got easier to crash? Although I don't think that should have happened..
(restarting dovecot did not change this - permanent storage? fluke?).
Restarting Dovecot rarely helps with anything. All state is stored in index files.
(gdb) p ret $4 = 15376
Wonder if this could also be wrong and caused by gdb being confused, because -O2 was used. I don't see any way how this could happen with the current code.