[Dovecot] 1.1.13 squat core dump
While using 1.1.13 and squat with local pine imap on Solaris 9 I had a random core dump today. I was doing a search in a maildir folder with about 2000 emails. Unfortunately, I haven't been able to reproduce it yet, but I wanted to send along the info anyways.
Environment:
uname -a
SunOS 5.9 Generic_122300-39 sun4u sparc SUNW,Sun-Blade-100
Backtrace:
~# dovecot -n
1.1.13: /usr/local/etc/dovecot.conf
OS: SunOS 5.9 sun4u
protocols: imap imaps pop3 pop3s ssl_disable: yes disable_plaintext_auth: no login_dir: /usr/local/var/run/dovecot/login login_executable(default): /usr/local/libexec/dovecot/imap-login login_executable(imap): /usr/local/libexec/dovecot/imap-login login_executable(pop3): /usr/local/libexec/dovecot/pop3-login login_greeting_capability(default): yes login_greeting_capability(imap): yes login_greeting_capability(pop3): no mail_location: maildir:~/Maildir:INDEX=/heroes/u1/dovecot-index/sparc/index/%u:CONTROL=/heroes/u1/dovecot-index/control/%u mmap_disable: yes mail_nfs_storage: yes mail_nfs_index: yes mail_executable(default): /usr/local/libexec/dovecot/imap mail_executable(imap): /usr/local/libexec/dovecot/imap mail_executable(pop3): /usr/local/libexec/dovecot/pop3 mail_plugins(default): quota imap_quota fts fts_squat mail_plugins(imap): quota imap_quota fts fts_squat mail_plugins(pop3): quota mail_plugin_dir(default): /usr/local/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/lib/dovecot/imap mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3 pop3_uidl_format(default): %08Xu%08Xv pop3_uidl_format(imap): %08Xu%08Xv pop3_uidl_format(pop3): UID%u-%v namespace: type: private separator: . prefix: INBOX. inbox: yes list: yes subscriptions: yes auth default: passdb: driver: pam args: * userdb: driver: passwd plugin: quota: fs fts: squat fts_squat: partial=4 full=4
--
David Halik System Administrator OIT-CSS Rutgers University dhalik@jla.rutgers.edu
On 4/21/2009, David Halik (dhalik@jla.rutgers.edu) wrote:
OS: SunOS 5.9 sun4u protocols: imap imaps pop3 pop3s
ssl_disable: yes
Not an answer to your issue, but was that the actual output of dovecot -n? Or did something get messed up when you pasted it?
The protocols line should have been on its own line, and I think the full output of uname -a should have been on the # OS: line...
--
Best regards,
Charles
My mistake, bad copy and paste:
dovecot -n
1.1.13: /usr/local/etc/dovecot.conf
OS: SunOS 5.9 sun4u
protocols: imap imaps pop3 pop3s
Charles Marcus wrote:
On 4/21/2009, David Halik (dhalik@jla.rutgers.edu) wrote:
OS: SunOS 5.9 sun4u protocols: imap imaps pop3 pop3s
ssl_disable: yes
Not an answer to your issue, but was that the actual output of dovecot -n? Or did something get messed up when you pasted it?
The protocols line should have been on its own line, and I think the full output of uname -a should have been on the # OS: line...
--
David Halik System Administrator OIT-CSS Rutgers University dhalik@jla.rutgers.edu
On 4/21/2009, David Halik (dhalik@jla.rutgers.edu) wrote:
My mistake, bad copy and paste:
dovecot -n
1.1.13: /usr/local/etc/dovecot.conf
OS: SunOS 5.9 sun4u protocols: imap imaps pop3 pop3s
? Like I said, the 'protocols' line should be on its own line, like:
myhost # dovecot -n
1.1.13: /etc/dovecot/dovecot.conf
OS: Linux 2.6.23-gentoo-r9 x86_64 Gentoo Base System release 1.12.11.1
protocols: imaps listen: [::] ... etc...
--
Best regards,
Charles
Yes, I understand what you're saying. My client is wrapping it and did again in the last email. I'll try and break it up, but it doesn't really matter, the info that is there is correct:
OS: SunOS 5.9 sun4u
protocols: imap imaps pop3 pop3s
Charles Marcus wrote:
On 4/21/2009, David Halik (dhalik@jla.rutgers.edu) wrote:
My mistake, bad copy and paste:
dovecot -n
1.1.13: /usr/local/etc/dovecot.conf
OS: SunOS 5.9 sun4u protocols: imap imaps pop3 pop3s
? Like I said, the 'protocols' line should be on its own line, like:
myhost # dovecot -n
1.1.13: /etc/dovecot/dovecot.conf
OS: Linux 2.6.23-gentoo-r9 x86_64 Gentoo Base System release 1.12.11.1
protocols: imaps listen: [::] ... etc...
--
David Halik System Administrator OIT-CSS Rutgers University dhalik@jla.rutgers.edu
On Apr 21, 2009, at 12:00 PM, David Halik wrote:
While using 1.1.13 and squat with local pine imap on Solaris 9 I had
a random core dump today. I was doing a search in a maildir folder
with about 2000 emails. Unfortunately, I haven't been able to
reproduce it yet, but I wanted to send along the info anyways.
Did you happen to get a core dump? gdb backtrace would be helpful: http://dovecot.org/bugreport.html
BTW. Has Squat been useful for you? I've noticed that with my very
very old Sun box it typically takes longer to update the indexes (even
for few mails) than to just perform the search unindexed. The
algorithm really could be made better..
Timo Sirainen wrote:
Did you happen to get a core dump? gdb backtrace would be helpful: http://dovecot.org/bugreport.html
The backtrace was in the email. Check the pastebin link:
BTW. Has Squat been useful for you? I've noticed that with my very very old Sun box it typically takes longer to update the indexes (even for few mails) than to just perform the search unindexed. The algorithm really could be made better..
I have noticed that updating the index for new mail is pretty slow. I wouldn't say it's slower than the search without it though. It's useful when you have a couple thousand emails and want to do multiple searches because each successive search is fast. We're actually running it on our Sun boxes in preparation for running it on faster linux boxes though, so I'm not to worried.
--
David Halik System Administrator OIT-CSS Rutgers University dhalik@jla.rutgers.edu
Timo,
I had another core dump randomly while doing a search with squat on. The backtrace is in the link:
Thanks.
David Halik wrote:
Timo Sirainen wrote:
Did you happen to get a core dump? gdb backtrace would be helpful: http://dovecot.org/bugreport.html
The backtrace was in the email. Check the pastebin link:
BTW. Has Squat been useful for you? I've noticed that with my very very old Sun box it typically takes longer to update the indexes (even for few mails) than to just perform the search unindexed. The algorithm really could be made better..
I have noticed that updating the index for new mail is pretty slow. I wouldn't say it's slower than the search without it though. It's useful when you have a couple thousand emails and want to do multiple searches because each successive search is fast. We're actually running it on our Sun boxes in preparation for running it on faster linux boxes though, so I'm not to worried.
--
David Halik System Administrator OIT-CSS Rutgers University dhalik@jla.rutgers.edu
Just an update. After I restarted pine and went back into the same folder to start the search over, I had a corruption notice which is probably from the crash:
Apr 23 09:47:20 host IMAP(user): : Corrupted squat uidlist file
/heroes/u1/dovecot-index/sparc/index/user/.bogounsure/dovecot.index.search.uids: wrong indexid
David Halik wrote:
Timo,
I had another core dump randomly while doing a search with squat on. The backtrace is in the link:
Thanks.
David Halik wrote:
Timo Sirainen wrote:
Did you happen to get a core dump? gdb backtrace would be helpful: http://dovecot.org/bugreport.html
The backtrace was in the email. Check the pastebin link:
BTW. Has Squat been useful for you? I've noticed that with my very very old Sun box it typically takes longer to update the indexes (even for few mails) than to just perform the search unindexed. The algorithm really could be made better..
I have noticed that updating the index for new mail is pretty slow. I wouldn't say it's slower than the search without it though. It's useful when you have a couple thousand emails and want to do multiple searches because each successive search is fast. We're actually running it on our Sun boxes in preparation for running it on faster linux boxes though, so I'm not to worried.
--
David Halik System Administrator OIT-CSS Rutgers University dhalik@jla.rutgers.edu
I did some more digging and here's the actual error that it fails with:
Apr 23 09:28:21 batman.rutgers.edu IMAP(kmech): : [ID 107833 mail.crit] Panic: file squat-trie.c: line 441: assertion failed: (!node->have_sequential)
Apr 23 09:28:21 batman.rutgers.edu IMAP(kmech): : [ID 398108 mail.error] Raw backtrace: 0x184dfc -> 0x18491c -> 0xfef190a8 -> 0xfef1b6c4 -> 0xfef1b8e8 -> 0xfef1b8e8 -> 0xfef1b8e8 -> 0xfef1b8e8 -> 0xfef1b8e8 -> 0xfef1b8e8 -> 0xfef1b9f8 -> 0xfef1dffc -> 0xfef1e418 -> 0xfef16d0c -> 0xfef445ec -> 0xfef47864 -> 0xfef48220 -> 0x11f2e4 -> 0x86124 -> 0x86458 -> 0x193170 -> 0x193200 -> 0x193f04 -> 0x193290 -> 0xa4308 -> 0x77368
Sorry for sending this in multiple emails, I'm trying to help someone debug it and I'm not getting the info all at once.
David Halik wrote:
Just an update. After I restarted pine and went back into the same folder to start the search over, I had a corruption notice which is probably from the crash:
Apr 23 09:47:20 host IMAP(user): : Corrupted squat uidlist file
/heroes/u1/dovecot-index/sparc/index/user/.bogounsure/dovecot.index.search.uids: wrong indexid
David Halik wrote:
Timo,
I had another core dump randomly while doing a search with squat on. The backtrace is in the link:
Thanks.
David Halik wrote:
Timo Sirainen wrote:
Did you happen to get a core dump? gdb backtrace would be helpful: http://dovecot.org/bugreport.html
The backtrace was in the email. Check the pastebin link:
BTW. Has Squat been useful for you? I've noticed that with my very very old Sun box it typically takes longer to update the indexes (even for few mails) than to just perform the search unindexed. The algorithm really could be made better..
I have noticed that updating the index for new mail is pretty slow. I wouldn't say it's slower than the search without it though. It's useful when you have a couple thousand emails and want to do multiple searches because each successive search is fast. We're actually running it on our Sun boxes in preparation for running it on faster linux boxes though, so I'm not to worried.
--
David Halik System Administrator OIT-CSS Rutgers University dhalik@jla.rutgers.edu
On Thu, 2009-04-23 at 11:51 -0400, David Halik wrote:
I did some more digging and here's the actual error that it fails with:
Apr 23 09:28:21 batman.rutgers.edu IMAP(kmech): : [ID 107833 mail.crit] Panic: file squat-trie.c: line 441: assertion failed: (!node->have_sequential)
Are you still getting these? If you can get it into a state where you can reproduce the crash every time when doing something, I'd like to get all the index files from that mailbox (except dovecot.index.cache isn't necessary and it contains parts of message headers).
If I can't reproduce it I don't think I'm going to spend time anytime soon on figuring out why it's crashing.
Timo,
I sense a v 1.1.16 is getting ready to hatch? True story? :-)
B. Bodger
On Sunday 17 May 2009 20:27:20 Bruce Bodger wrote:
Timo,
I sense a v 1.1.16 is getting ready to hatch? True story? :-)
B. Bodger
Someone needs to learn how to count. :P
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On May 17, 2009, at 7:31 PM, Brad wrote:
On Sunday 17 May 2009 20:27:20 Bruce Bodger wrote:
Timo,
I sense a v 1.1.15 is getting ready to hatch? True story? :-)
B. Bodger
Someone needs to learn how to count. :P
Don't know what you mean? <wink> :-)
B. Bodger
So far the crashes continue, but I haven't seen anything in particular that sets it off. I'll trying coming up with a way of reproducing it and get back to you if I can. In the meantime, I'm upgrading to the latest version to see if anything changes.
Timo Sirainen wrote:
On Thu, 2009-04-23 at 11:51 -0400, David Halik wrote:
I did some more digging and here's the actual error that it fails with:
Apr 23 09:28:21 batman.rutgers.edu IMAP(kmech): : [ID 107833 mail.crit] Panic: file squat-trie.c: line 441: assertion failed: (!node->have_sequential)
Are you still getting these? If you can get it into a state where you can reproduce the crash every time when doing something, I'd like to get all the index files from that mailbox (except dovecot.index.cache isn't necessary and it contains parts of message headers).
If I can't reproduce it I don't think I'm going to spend time anytime soon on figuring out why it's crashing.
--
David Halik System Administrator OIT-CSS Rutgers University dhalik@jla.rutgers.edu
participants (5)
-
Brad
-
Bruce Bodger
-
Charles Marcus
-
David Halik
-
Timo Sirainen