On Feb 22, 2018, at 15:21, Josef 'Jeff' Sipek <jeff.sipek@dovecot.fi> wrote:
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)
No difference there. I changed the install process to not strip things, and manually copied in all of the libs in /usr/local/lib/dovecot again with unstripped (I think libtool stripped them, I just rejiggered makefiles and install-sh).
Loading a core from a SEGV shows:
Loaded symbols for /libexec/ld-elf.so.1 #0 __unaligned_load ( p=0x706172736572690a <Address 0x706172736572690a out of bounds>, size=4) at /usr/src/lib/libc/sparc64/sys/__sparc_utrap_align.c:45 45 val = (val << 8) | p[i]; (gdb) bt full #0 __unaligned_load ( p=0x706172736572690a <Address 0x706172736572690a out of bounds>, size=4) at /usr/src/lib/libc/sparc64/sys/__sparc_utrap_align.c:45 val = 0 i = 0 #1 0x0000000040adb7cc in __unaligned_fixup (uf=0x7fdfffff110) at /usr/src/lib/libc/sparc64/sys/__sparc_utrap_align.c:78 addr = <value optimized out> val = <value optimized out> insn = 3254806592 sig = <value optimized out> #2 0x0000000040adb5b0 in __sparc_utrap (uf=0x7fdfffff110) at /usr/src/lib/libc/sparc64/sys/__sparc_utrap.c:100 sig = 16 #3 0x0000000040a2c1cc in __sparc_utrap_gen () from /lib/libc.so.7 No symbol table info available. #4 0x0000000040a2c1cc in __sparc_utrap_gen () from /lib/libc.so.7 No symbol table info available. Previous frame identical to this frame (corrupt stack?) (gdb)
(Which as you note below, that address is actually “parseri\n”)
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.
Unfortunately it seems not to have. But, good catch on the pointer value there being ASCII data. Let me know if you have any other ideas.
- Chris