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- on FreeBSD 11 on sparc64.
>   Trying to debug a problem I was having with one of my clients, I
>   upgraded to dovecot- 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

(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

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.



>     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

Reply via email to