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
, 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:45val = 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