Bug ID | 1051848 |
---|---|
Summary | server:mail/cyrus-imapd: proxy segfault after upgrade to 2.4.19-149.1 |
Classification | openSUSE |
Product | openSUSE.org |
Version | unspecified |
Hardware | Other |
OS | SLES 11 |
Status | NEW |
Severity | Normal |
Priority | P5 - None |
Component | 3rd party software |
Assignee | opensuse-communityscreening@forge.provo.novell.com |
Reporter | wullinger@rz.uni-kiel.de |
QA Contact | opensuse-communityscreening@forge.provo.novell.com |
Found By | --- |
Blocker | --- |
We use cyrus imapd 2.4 in a proxy configuration for multiple mailbox storage servers. Since upgrading to 2.4.19-149.1, the frontend proxies (and only those) experience frequent segfaults of pop3d, proxyd, timsieved, and lmptproxyd: Aug 2 06:16:31 frontend3 kernel: [488770.024881] pop3d[XXXX]: segfault at 7f42ef735738 ip 00007f42ef546ca3 sp 00007ffdd7a45970 error 4 in ld-2.11.3.so[7f42ef539000+1f000] The problems disappears after downgrading back to cyrus-imapd-2.4.19-146.1. After such a crash, the BDB environment is often reported as needing recovery (we only use skiplist DBs, but BDB gets initialized nonetheless) As far as we can tell, there's no interruption of service associated with these crashes. For example, for lmtpproxyd, the problem seems to appear after the final QUIT, when the process is about to exit, anyway: write(13, "QUIT\r\n", 6) = 6 rt_sigprocmask(SIG_BLOCK, [INT QUIT ALRM TERM CHLD], [], 8) = 0 pselect6(14, [13], NULL, NULL, {229, 0}, {[], 8}) = 1 (in [13], left {228, 999487532}) rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 read(13, "221 2.0.0 bye\r\n", 4096) = 15 rt_sigprocmask(SIG_BLOCK, [INT QUIT ALRM TERM CHLD], [], 8) = 0 pselect6(14, [13], NULL, NULL, {0, 0}, {[], 8}) = 1 (in [13], left {0, 0}) rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 read(13, "", 4096) = 0 shutdown(13, 0 /* receive */) = 0 close(13) = 0 munmap(0x7f87be793000, 38608896) = 0 close(8) = 0 munmap(0x7f87c693f000, 40960) = 0 munmap(0x7f87c6873000, 98304) = 0 munmap(0x7f87c1aca000, 28131328) = 0 munmap(0x7f87c688b000, 671744) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- A slight hunch seems to suggest that there's a memory corruption issue that gets triggered during the final close of the BDB environment.