On Tue, Feb 20, 2018 at 19:08:27 -0500, 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: > ... > Loading the core file, as described > https://www.dovecot.org/bugreport.html , shows the error in libc > somewhere:
I read the your other mails in this thread; can you run things as before and do a 'bt full' on the core file with the debug-symbol-enabled libdovecot? gdb seems to be catching the SIGTRAPs, which is making things a bit confusing. > (gdb) bt full > #0 __unaligned_load ( > p=0x617070656e640e6d <Address 0x617070656e640e6d out of bounds>, size=4) This address looks like ASCII - "append\x0em", so my theory at the moment is: (1) something clobbers a pointer (2) the CPU attempts to execute a load from the address (3) a utrap is generated to handle unaligned load (4) the utrap code attempts to emulate the unaligned load (5) the CPU fails to access the address since it is bogus, and a SIGSEGV is generated Now, I'm have no idea why it'd first try to work around the alignment requirement before doing a quick sanity check and generating SIGSEGV to begin with, but that's my theory based on the info available so far. Hopefully, a stack trace from a core file will help. Thanks, Jeff. > 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 -- If I have trouble installing Linux, something is wrong. Very wrong. - Linus Torvalds