Open peterhoeg opened 1 month ago
I've seen this occasionally... what Xapian version are you using?
I should have added that in earlier, apologies.
It's 1.4.25
All dependencies are shown below.
Just happened again but with a different error:
Database couldn't be opened for reading: DatabaseCorruptError: Expected block 104050 to be level 3, not 0
Continuing check anyway
docdata:
blocksize=8K items=791426 firstunused=77160 revision=236 levels=2 root=6263
B-tree checked okay
docdata table structure checked OK
termlist:
blocksize=8K items=1582852 firstunused=142454 revision=236 levels=2 root=14600
B-tree checked okay
termlist table structure checked OK
postlist:
xapian-check: DatabaseCorruptError: Expected block 104050 to be level 3, not 0
And a different error again:
docdata:
blocksize=8K items=790419 firstunused=77826 revision=1773 levels=2 root=6812
B-tree checked okay
docdata table structure checked OK
termlist:
blocksize=8K items=1580838 firstunused=143486 revision=1773 levels=2 root=13888
B-tree checked okay
termlist table structure checked OK
postlist:
blocksize=8K items=3734630 firstunused=203197 revision=1773 levels=3 root=22505
xapian-check: DatabaseError: Block 45602 item 51: key >= right dividing key in level above
... working on this.
Is there anything I can do or any additional information that would be helpful?
I'll let you know when I have something for testing. Hopefully this week.
I didn't mean to chase/rush you - I was just thinking if there was anything I could do to help.
There's a new error just now:
docdata:
blocksize=8K items=790760 firstunused=52993 revision=2499 levels=2 root=1389
B-tree checked okay
docdata table structure checked OK
termlist:
blocksize=8K items=1581520 firstunused=147135 revision=2499 levels=2 root=144033
B-tree checked okay
termlist table structure checked OK
postlist:
blocksize=8K items=3751217 firstunused=211301 revision=2499 levels=3 root=55552
xapian-check: DatabaseError: Block 206577 item 65: not in sorted order
I think the problem is with multiple writers / transactions to the Xapian database. It's not really documented exactly what Xapian allows, but likely mu broke a few rules.
Anyway, there's wip/djcb/store-worker
which ensures all writes and mu4e commands are handled in a single thread. Works fine for me, with a few (cosmetic) things I want to fix before merging into master
. But, should hopefully address the errors you're seeing.
I am still seeing corruption with that branch (commit: 920dbb6a796b6b87da8d44fb491190f918efd7a9):
position: blocksize=8K items=147226877 firstunused=510123 revision=2056 levels=3 root=445762 B-tree checked okay docdata: blocksize=8K items=791953 firstunused=78160 revision=2056 levels=2 root=270 B-tree checked okay docdata table structure checked OK
termlist: blocksize=8K items=1583906 firstunused=144285 revision=2056 levels=2 root=294 B-tree checked okay termlist table structure checked OK
postlist: blocksize=8K items=3751260 firstunused=204576 revision=2056 levels=3 root=95984 B-tree checked okay Failed to unpack wdf termfreq 496 != # of entries 58751 postlist table errors found: 2
position: blocksize=8K items=147226877 firstunused=510123 revision=2056 levels=3 root=445762 B-tree checked okay position table structure checked OK
spelling: Lazily created, and not yet used.
synonym: Lazily created, and not yet used.
Total errors found: 2
On a separate note, due to how things work on NixOS, changing mu also causes a rebuild of mu4e and mu4e doesn’t like the version tag you used 1.12.6-α. I had to patch it to 1.12.5.1 for mu4e to not blow up.
mu4e has also been hanging for with this branch when performing searches. Sending USR2 to the emacs process makes it respond again for a few seconds before hanging again, so I have taken a screenshot of the errors rather than copying out the text as I simply wasn’t fast enough to “get it out” before emacs would hang again.
I have confirmed no errors on the DB by running xapian-check.
EDIT: Let me just elaborate what happens when it hangs:
Thanks for testing; yes, there's some issue the indexing in the indexing state machine, working on that. For now 1.12.5 is probably better for now...
However, did you see database corruption with the branch with xapian-check
? Your two messages seems a bit a contradictory. Thanks!
Sequence of events:
I'm wondering if there is anything special about my setup that's triggering this considering nobody else is experiencing it. Anything you can suggest/any workarounds to try out?
I don't know... I'm seeing it occasionally.
I only started seeing it recently, perhaps after some system upgrade. I suspect it's some unsafe access to the Xapian database, and some newer versions of Xapian are less forgiving. But.. this is all just speculation.
The "unsafest" time might be trying to use mu while indexing is underway; so not doing that may help. But who knows.
Describe the bug I have been experiencing repeated database corruption on 2 different machines (a desktop and a laptop). I don't know if this is a xapian issue or mu-specific but it's been happening for a while now since the 1.11.x version of mu.
The message about corruption is different from time to time. It just happened again which is why I'm opening this issue and this time the message is:
As far as I recall, the error has always been with the
postlist
although the messages differ.To Reproduce There are no specific steps to reproduce - this has been happening once a week or so for quite some time.
Environment NixOS 24.05, Emacs 29.3, latest mu (1.12.5 presently), Xapian 1.4.25
Checklist
master
(otherwise, please upgrade).