Re: [Dovecot] New to dovecot, little luck - signal 10 death for imap
Peter Evans wrote:
Jeroen Scheerder (Jeroen.Scheerder@phil.uu.nl) wrote:
However, whenever a mailbox is selected, the imap subprocess dies. Jul 13 14:52:05 localhost dovecot: imap-login: Login: js [127.0.0.1] Jul 13 14:52:07 localhost dovecot: child 8082 (imap) killed with signal 10
You're going to have to help us to help you. 10 is bus error (I think) which is badness.
OS, version of dovecot etc.
you might want to debug a coredump, that will tell you where/why its dying too.
I would merrily gdb into a coredump and stacktrace away, if a core dump were created. No such luck.
I'm now logging directly to file using syslog, after having started dovecot. There is no limit on coredumps:
% limit cputime unlimited filesize unlimited datasize unlimited stacksize 8MB coredumpsize unlimited descriptors 64 vmemorysize unlimited % more /tmp/dovecot* :::::::::::::: /tmp/dovecot-info.log :::::::::::::: dovecot: Jul 13 15:27:35 Info: Dovecot v1.0-stable starting up dovecot: Jul 13 15:28:21 Info: imap-login: Login: avank [127.0.0.1] :::::::::::::: /tmp/dovecot.log :::::::::::::: dovecot: Jul 13 15:28:21 Error: child 14882 (imap) killed with signal 10
Environmental details:
Solaris 7 (sparc)
dovecot 1.0-stable
compiled with ldap support
using gcc 3.3.4
4.0.0
4.0.1 (no difference here)
configured for mbox support
with locking matching procmail's delivery locking strategies
with authentication using passwd/shadow native databasesA header dump shows nothing suspect:
% elfdump -d /phil/sunos/sparc/pkg/dovecot-1.0-stable/libexec/dovecot/imap
Dynamic Section: .dynamic index tag value [0] NEEDED 0x1 libsocket.so.1 [1] NEEDED 0x117 librt.so.1 [2] NEEDED 0x140 libc.so.1 [3] NEEDED 0x397 libnsl.so.1 [4] NEEDED 0x3b3 libdl.so.1 [5] RPATH 0x3cc /phil/sw/sunos/sparc/lib [snip]
Will try on Solaris 10.
On Wed, 2005-07-13 at 15:33 +0200, Jeroen Scheerder wrote:
Peter Evans wrote:
Jeroen Scheerder (Jeroen.Scheerder@phil.uu.nl) wrote:
However, whenever a mailbox is selected, the imap subprocess dies. Jul 13 14:52:05 localhost dovecot: imap-login: Login: js [127.0.0.1] Jul 13 14:52:07 localhost dovecot: child 8082 (imap) killed with signal 10
You're going to have to help us to help you. 10 is bus error (I think) which is badness.
OS, version of dovecot etc.
you might want to debug a coredump, that will tell you where/why its dying too.
I would merrily gdb into a coredump and stacktrace away, if a core dump were created. No such luck.
I would be surprized, if you got a coredump with signal 10. Are you sure that signal 10 is SIGBUS? Coredumps are normally created only upon sigsev (=11).
Try kill -l and find out the real meaning of the signal. Here (under linux) 10 = SIGUSR, whereas SIGBUS = 7.
... although that doesn't reveal anything more useful. SIGUSR is probably even worse than SIGBUS ...
Udo
-- bestsolution.at EDV Systemhaus GmbH http://www.bestsolution.at
Udo Rader (13/7/05 15:42 +0200) [Re: [Dovecot] New to dovecot, little luck - signal 10 death]:
[...]
I would be surprized, if you got a coredump with signal 10. Are you sure that signal 10 is SIGBUS? Coredumps are normally created only upon sigsev (=11).
Try kill -l and find out the real meaning of the signal. Here (under linux) 10 = SIGUSR, whereas SIGBUS = 7.
... although that doesn't reveal anything more useful. SIGUSR is probably even worse than SIGBUS ...
Yes, I think it's SIGBUS.
$ kill -l HUP INT QUIT ILL TRAP IOT EMT FPE KILL BUS SEGV SYS PIPE ALRM TERM USR1 USR2 CHLD PWR WINCH URG POLL STOP TSTP CONT TTIN TTOU VTALRM PROF XCPU XFSZ WAITING LWP FREEZE THAW CANCEL LOST RTMIN 39 40 41 42 43 44 RTMAX
$ grep -E "10 " /usr/include/sys/signal.h #define SIGBUS 10 /* bus error */
Jeroen Scheerder wrote:
I would merrily gdb into a coredump and stacktrace away, if a core dump were created. No such luck.
Do you have "mail_drop_priv_before_exec" set? It'll prevent core dumps if so. Also, the core file probably ends up in the user's home directory. I've found that I needed a patch that had been published earlier on this list (see http://dovecot.org/pipermail/dovecot/2005-January/005926.html) for 64-bit Sparc (Solaris 8). I haven't tried it without the patch recently, so I'm not sure whether the problem still exists, and memcpy, casts etc. are a bit too technical for me anyway! diff -ruN dovecot-1.0-stable.orig/src/lib-storage/index/mbox/mbox-file.c dovecot -1.0-stable/src/lib-storage/index/mbox/mbox-file.c --- dovecot-1.0-stable.orig/src/lib-storage/index/mbox/mbox-file.c Mon Jan 31 16:37:55 2005 +++ dovecot-1.0-stable/src/lib-storage/index/mbox/mbox-file.c Sun Mar 20 12:18 :34 2005 @@ -120,7 +120,9 @@ return -1; } - offset = *((const uint64_t *)data); +/* CDW, see - http://dovecot.org/pipermail/dovecot/2005-January/005926.html */ +/* offset = *((const uint64_t *)data); CDW */ + memcpy(&offset,data,sizeof(uint64_t)); if (istream_raw_mbox_seek(ibox->mbox_stream, offset) < 0) { if (offset == 0) { mail_storage_set_critical(ibox->box.storage, -- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
Chris Wakelin (13/7/05 15:00 +0100) [Re: [Dovecot] New to dovecot, little luck - signal 10 death]:
I've found that I needed a patch that had been published earlier on this list (see http://dovecot.org/pipermail/dovecot/2005-January/005926.html) for 64-bit Sparc (Solaris 8). I haven't tried it without the patch recently, so I'm not sure whether the problem still exists, and memcpy, casts etc. are a bit too technical for me anyway!
That patch still works, and is needed. I'm looking at a good-looking
-*-Mutt: imap://localhost/INBOX [Msgs:1312 Old:877 Del:5]window right now. Thanks!
On Wed, 2005-07-13 at 15:00 +0100, Chris Wakelin wrote:
- offset = *((const uint64_t *)data); +/* CDW, see - http://dovecot.org/pipermail/dovecot/2005-January/005926.html */ +/* offset = *((const uint64_t *)data); CDW */ + memcpy(&offset,data,sizeof(uint64_t));
Although this works, this wasn't really how I wanted to fix this. I think this should work (indexes need to be recreated afterwards): Index: lib-index/mail-index-sync-ext.c =================================================================== RCS file: /var/lib/cvs/dovecot/src/lib-index/mail-index-sync-ext.c,v retrieving revision 1.9 diff -u -r1.9 mail-index-sync-ext.c --- lib-index/mail-index-sync-ext.c 4 Jul 2005 11:32:20 -0000 1.9 +++ lib-index/mail-index-sync-ext.c 13 Jul 2005 15:50:14 -0000 @@ -169,7 +169,7 @@ struct mail_index_map *new_map; struct mail_index_ext *ext, **sorted; struct mail_index_ext_header *ext_hdr; - uint16_t *old_offsets, min_align; + uint16_t *old_offsets, min_align, max_align; uint32_t offset, old_records_count, rec_idx; unsigned int i, count; const void *src; @@ -192,9 +192,13 @@ requirement first. FIXME: if the extension sizes don't match alignmentation, this may not give the minimal layout. */ offset = sizeof(struct mail_index_record); + max_align = sizeof(uint32_t); for (;;) { min_align = (uint16_t)-1; for (i = 0; i < count; i++) { + if (sorted[i]->record_align > max_align) + max_align = sorted[i]->record_align; + if (sorted[i]->record_offset == 0) { if ((offset % sorted[i]->record_align) == 0) break; @@ -218,9 +222,9 @@ i_assert(offset < (uint16_t)-1); } - if ((offset % sizeof(uint32_t)) != 0) { - /* keep 32bit alignment */ - offset += sizeof(uint32_t) - (offset % sizeof(uint32_t)); + if ((offset % max_align) != 0) { + /* keep record size divisible with maximum alignment */ + offset += max_align - (offset % max_align); } /* create a new mapping without records. a bit kludgy. */
Timo Sirainen wrote:
[...]
+/* CDW, see - http://dovecot.org/pipermail/dovecot/2005-January/005926.html */ +/* offset = *((const uint64_t *)data); CDW */
memcpy(&offset,data,sizeof(uint64_t));Although this works, this wasn't really how I wanted to fix this. I think this should work (indexes need to be recreated afterwards):
This patch doesn't work. The "memcpy" patch does, however.
After applying this patch to todays 1.0-stable and building that, I once again get:
dovecot: Jul 14 08:05:25 Error: child 8702 (imap) killed with signal 10
This does happen further down the road, apparently when a client is done fetching headers in a mailbox.
On 14.7.2005, at 09:11, Jeroen Scheerder wrote:
Although this works, this wasn't really how I wanted to fix this. I think this should work (indexes need to be recreated afterwards):
This patch doesn't work. The "memcpy" patch does, however.
After applying this patch to todays 1.0-stable and building that, I once again get:
dovecot: Jul 14 08:05:25 Error: child 8702 (imap) killed with signal 10
This does happen further down the road, apparently when a client is done fetching headers in a mailbox.
But did you delete Dovecot's index files first? It can't fix the old files .. although I guess I should add a check for that too. If that didn't help, could you get a backtrace of the crash? http://dovecot.org/bugreport.html explains a few ways to do it.
Timo Sirainen wrote:
[patch to enforce proper alignment that I thought did not work]
But did you delete Dovecot's index files first? It can't fix the old files .. although I guess I should add a check for that too.
No, I didn't do that. I mistook your remark to mean that things would take a little longer. I had seen claims about extensive validation at work for these indexfiles, so I never gave that much thought. Perhaps an extra check would be good, even if it's just to deal with fools like me.
If that didn't help, could you get a backtrace of the crash? http://dovecot.org/bugreport.html explains a few ways to do it.
I can confirm now that it does work after all. Thanks!
Jeroen Scheerder wrote:
Timo Sirainen wrote:
[patch to enforce proper alignment that I thought did not work]
But did you delete Dovecot's index files first? It can't fix the old files .. although I guess I should add a check for that too.
...
I can confirm now that it does work after all. Thanks!
Works for me too (Solaris 8 Sparc).
Best Wishes, Chris
-- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
participants (4)
-
Chris Wakelin
-
Jeroen Scheerder
-
Timo Sirainen
-
Udo Rader