Your core dump looks a bit broken. Since it seems to die instantly, can you try gdb /path/to/auth and just run it?
Aki On 21.02.2018 02:08, Chris Ross wrote: > Apologies first for using two addresses, but I can’t currently read my > email at distal.com. :-) > > I was previously running dovecot2-2.2.29.1_2 on FreeBSD 11 on sparc64. > Trying to debug a problem I was having with one of my clients, I upgraded to > dovecot-2.2.33.2_4 on that same server. However, I cannot connect now, log > shows: > > Feb 20 16:55:00 westeros dovecot: master: Dovecot v2.2.33.2 (d6601f4ec) > starting up for imap, pop3, lmtp > Feb 20 16:55:31 westeros dovecot: auth: Fatal: master: service(auth): child > 25395 killed with signal 11 (core dumped) > Feb 20 16:55:31 westeros dovecot: master: Error: service(auth): command > startup failed, throttling for 2 secs > Feb 20 16:55:31 westeros dovecot: imap-login: Disconnected: Auth process > broken (disconnected before auth was ready, waited 0 secs): user=<>, > rip=2001::xxx, lip=2001:470:e24c:200::ae25, TLS handshaking, > session=<ASDFSAFSADFSAD> > Feb 20 16:55:33 westeros dovecot: auth: Fatal: master: service(auth): child > 25398 killed with signal 11 (core dumped) > Feb 20 16:55:33 westeros dovecot: master: Error: service(auth): command > startup failed, throttling for 4 secs > Feb 20 16:55:33 westeros dovecot: imap-login: Disconnected: Auth process > broken (disconnected before auth was ready, waited 2 secs): user=<>, > rip=2001::xxx, lip=2001:470:e24c:200::ae25, session=<d46tyesdy5dsyd> > Feb 20 16:55:37 westeros dovecot: master: Error: service(auth): command > startup failed, throttling for 8 secs > Feb 20 16:55:37 westeros dovecot: auth: Fatal: master: service(auth): child > 25400 killed with signal 11 (core dumped) > > Loading the core file, as described https://www.dovecot.org/bugreport.html > , shows the error in libc somewhere: > > (gdb) bt full > #0 __unaligned_load ( > p=0x617070656e640e6d <Address 0x617070656e640e6d out of bounds>, size=4) > at /usr/src/release-11.1.0/lib/libc/sparc64/sys/__sparc_utrap_align.c:45 > val = 0 > i = 0 > #1 0x00000000109f9f6c in __unaligned_fixup (uf=0x7fdffffee40) > at /usr/src/release-11.1.0/lib/libc/sparc64/sys/__sparc_utrap_align.c:78 > addr = <value optimized out> > val = <value optimized out> > insn = 3254807616 > sig = <value optimized out> > #2 0x00000000109f9d50 in __sparc_utrap (uf=0x7fdffffee40) > at /usr/src/release-11.1.0/lib/libc/sparc64/sys/__sparc_utrap.c:100 > sig = 272013984 > #3 0x000000001094a10c in __sparc_utrap_gen () from /lib/libc.so.7 > No symbol table info available. > #4 0x000000001094a10c in __sparc_utrap_gen () from /lib/libc.so.7 > No symbol table info available. > Previous frame identical to this frame (corrupt stack?) > (gdb) > > As this is a sparc64, with 8-byte alignment requirements, I’m guessing > that’s the issue. Many a piece of software has failed to respect that and > crashed. But, I’m not sure. > > Does anyone have any suggestions? I’ve built it locally (via ports), so if > there are compiler options I can/should try, I certainly can try. > > Thanks… > > - Chris
