Auth SEGV on sparc64, alignment problem?

[Chris Ross]

> On Feb 22, 2018, at 15:21, Josef 'Jeff' Sipek <jeff.sipek at 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