Re: Testing Firefox 62 on sparc64

[Romain Dolbeau <romain@dolbeau.org>]

2018-08-09 14:50 GMT+02:00 John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de>:
> Did you install the debug package so we can see where it actually
> crashes in ProcessExecutableMemory.cpp?

With 62.0~b16-1 on my t5120 (tunneled X11 - dunno if it changes the
behavior), running with the dbgsym package under gdb:

#####
Thread 1 "firefox" received signal SIGBUS, Bus error.
HashIIDPtrKey (key=0xffff80010a425aec <xpt::detail::sInterfaces+30352>)
    at /build/firefox-qTMIsZ/firefox-62.0~b16/js/xpconnect/src/XPCMaps.cpp:26
26      /build/firefox-qTMIsZ/firefox-62.0~b16/js/xpconnect/src/XPCMaps.cpp:
No such file or directory.
(gdb)
(gdb) bt
#0  HashIIDPtrKey (key=0xffff80010a425aec <xpt::detail::sInterfaces+30352>)
    at /build/firefox-qTMIsZ/firefox-62.0~b16/js/xpconnect/src/XPCMaps.cpp:26
#1  0xffff80010690aed4 in PLDHashTable::ComputeKeyHash (
    aKey=0xffff80010a425aec <xpt::detail::sInterfaces+30352>,
this=0x70000440140)
    at /build/firefox-qTMIsZ/firefox-62.0~b16/xpcom/ds/PLDHashTable.cpp:586
#2  PLDHashTable::Add (this=0x70000440140,
    aKey=0xffff80010a425aec <xpt::detail::sInterfaces+30352>)
    at /build/firefox-qTMIsZ/firefox-62.0~b16/xpcom/ds/PLDHashTable.cpp:586
#3  0xffff80010701a140 in IID2NativeInterfaceMap::Add
(iface=0x700004abfa0, this=0x70000440140)
    at /build/firefox-qTMIsZ/firefox-62.0~b16/js/xpconnect/src/XPCMaps.h:245
(...)
#####

>From the source package, the relevant source bit would be:

#####
static PLDHashNumber
HashIIDPtrKey(const void* key)
{
    return HashGeneric(*((uintptr_t*)key));
}
#####
Line 26 being the return.

#####
(gdb) disassemble
Dump of assembler code for function HashIIDPtrKey(void const*):
=> 0xffff800106fe206c <+0>:     ldx  [ %o0 ], %g3
   0xffff800106fe2070 <+4>:     add  %g3, %g3, %g2
   0xffff800106fe2074 <+8>:     srlx  %g3, 0x20, %g4
   0xffff800106fe2078 <+12>:    add  %g2, %g3, %g1
(...)
(gdb) print (uintptr_t*)key
$9 = (uintptr_t *) 0xffff80010a425aec <xpt::detail::sInterfaces+30352>
#####

So, yet another function that doesn't bother to check for alignment,
it seems... that pointer is aligned on 4 bytes, but not 8.

Cordially,

-- 
Romain Dolbeau