unexpunge segfaults with -l on some mailboxes
boutilpj at ednet.ns.ca
Thu Mar 12 18:48:05 EDT 2009
Bron Gondwana wrote:
> Not so good. Crap. And this is on 2.3.13? I don't see any changes
> touching that code in the post 2.3.13 changelogs...
Correct. We have been running 2.3.13 pretty much since it was released,
2.3.12 before that, and 2.3.11 before that.
>>> I'm tempted to protect the code from crashing though... we don't
>>> use unexpunge at FastMail, which is probably why I haven't already
>>> done so.
>>> Something like the attached should do it. I'll test it more
>>> completely and commit it to CVS for 2.3.14 (since Ken hasn't
>>> cut a release candidate yet!)
>> Thanks for the patch.
> Hey, don't use it though - it doesn't even compile! It was a first
> draft. I'll give you a real patch soon... been working on doing it
> _properly_ :)
>> Would ipurge be causing the corruption? We currently purge e-mails older
>> than 31 days on a weekly basis. I will turn that off for a bit (since
>> disk space is not as much of an issue as it used to be) and see if the
>> corruption returns.
> Oooh... maybe. I don't use ipurge. Let me know what you find with
> turning it off. I've never even _looked_ at that code.
The more I think of it, the more I believe that ipurge will be the
source of the problem. When I was manually checking for corruption (and
reconstructing the mailboxes that had problems) there would be no
corruption for 6 days. On the 7th day (always Sunday morning if I recall
correctly) corruption would reappear in many mailboxes. As it turns out,
our weekly ipurge ran on Saturday morning.
This will be real easy to test though. I will just run ipurge on a
subfolder of my mailbox and see if it corrupts it. :-)
More information about the Info-cyrus