Re: Testing Firefox 62 on sparc64
On 08/17/2018 12:20 PM, Romain Dolbeau wrote:
> 2018-08-09 14:50 GMT+02:00 John Paul Adrian Glaubitz
> :
>> 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=0x80010a425aec )
> 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:
This is exactly this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1434726
The patch is trivial:
diff --git a/js/xpconnect/src/XPCMaps.cpp b/js/xpconnect/src/XPCMaps.cpp
index bb99b9f8c034..837d5d78970f 100644
--- a/js/xpconnect/src/XPCMaps.cpp
+++ b/js/xpconnect/src/XPCMaps.cpp
@@ -23,7 +23,7 @@ using namespace mozilla;
static PLDHashNumber
HashIIDPtrKey(const void* key)
{
-return HashGeneric(*((uintptr_t*)key));
+return HashGeneric(((nsID*)key)->m0);
}
static bool
but not accepted upstream. We have to take a different approach using memcpy().
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Testing Firefox 62 on sparc64
2018-08-09 14:50 GMT+02:00 John Paul Adrian Glaubitz
:
> 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=0x80010a425aec )
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=0x80010a425aec )
at /build/firefox-qTMIsZ/firefox-62.0~b16/js/xpconnect/src/XPCMaps.cpp:26
#1 0x80010690aed4 in PLDHashTable::ComputeKeyHash (
aKey=0x80010a425aec ,
this=0x7440140)
at /build/firefox-qTMIsZ/firefox-62.0~b16/xpcom/ds/PLDHashTable.cpp:586
#2 PLDHashTable::Add (this=0x7440140,
aKey=0x80010a425aec )
at /build/firefox-qTMIsZ/firefox-62.0~b16/xpcom/ds/PLDHashTable.cpp:586
#3 0x80010701a140 in IID2NativeInterfaceMap::Add
(iface=0x74abfa0, this=0x7440140)
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*):
=> 0x800106fe206c <+0>: ldx [ %o0 ], %g3
0x800106fe2070 <+4>: add %g3, %g3, %g2
0x800106fe2074 <+8>: srlx %g3, 0x20, %g4
0x800106fe2078 <+12>:add %g2, %g3, %g1
(...)
(gdb) print (uintptr_t*)key
$9 = (uintptr_t *) 0x80010a425aec
#
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
Re: Testing Firefox 62 on sparc64
On 08/09/2018 04:54 PM, Gregor Riepl wrote: >> Yes, I know. But that means extra work with Vnc unless I want the pain that >> is X11 tunneling. > > ssh -X doesn't work for you? > It's usually relatively painless... usually. Of course, it does. It's just awfully slow. -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Testing Firefox 62 on sparc64
> Yes, I know. But that means extra work with Vnc unless I want the pain that > is X11 tunneling. ssh -X doesn't work for you? It's usually relatively painless... usually.
Re: Testing Firefox 62 on sparc64
On 08/09/2018 03:25 PM, Gregor Riepl wrote: >> It's an assertion that's triggered from here: >> >>> https://hg.mozilla.org/mozilla-central/file/tip/js/src/jit/ProcessExecutableMemory.cpp >> >> Did you install the debug package so we can see where it actually >> crashes in ProcessExecutableMemory.cpp? > > Yes, otherwise the backtrace wouldn't have included _any_ information at > all... Seems like it's still not very useful. > Perhaps I need to launch FF with special parameters to get meaningful output? Yes, but we're still missing the line numbers. >> Otherwise, I'll have to build from source and debug from there. > > You could run FF in Xvfb or via X11 tunneling if you don't have a workstation > with a screen, you know. ;) Yes, I know. But that means extra work with Vnc unless I want the pain that is X11 tunneling. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Testing Firefox 62 on sparc64
> It's an assertion that's triggered from here: > >> https://hg.mozilla.org/mozilla-central/file/tip/js/src/jit/ProcessExecutableMemory.cpp > > Did you install the debug package so we can see where it actually > crashes in ProcessExecutableMemory.cpp? Yes, otherwise the backtrace wouldn't have included _any_ information at all... Seems like it's still not very useful. Perhaps I need to launch FF with special parameters to get meaningful output? > Otherwise, I'll have to build from source and debug from there. You could run FF in Xvfb or via X11 tunneling if you don't have a workstation with a screen, you know. ;) I tried both on the machine's desktop and via ssh -X, resulting in the same crash, by the way.
Re: Testing Firefox 62 on sparc64
On 08/09/2018 02:41 PM, Gregor Riepl wrote: >> Could someone with a desktop installed on their sparc64 box please >> test the firefox package from experimental and check whether the >> alignment-related crash is still present [1]? > > I have bad news, unfortunately. :( > > firefox crashes (reproduceably) right after launch, and it seems it might be > something else: > > Thread 1 "firefox" received signal SIGSEGV, Segmentation fault. > MOZ_CrashOOL (aLine=, aReason=0xf8010a832550 > "js::jit::InitProcessExecutableMemory() failed") > at /build/firefox-mXaCXs/firefox-62.0~b10/mfbt/Assertions.cpp:33 > 33 in /build/firefox-mXaCXs/firefox-62.0~b10/mfbt/Assertions.cpp It's an assertion that's triggered from here: > https://hg.mozilla.org/mozilla-central/file/tip/js/src/jit/ProcessExecutableMemory.cpp Did you install the debug package so we can see where it actually crashes in ProcessExecutableMemory.cpp? Otherwise, I'll have to build from source and debug from there. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Testing Firefox 62 on sparc64
> Could someone with a desktop installed on their sparc64 box please > test the firefox package from experimental and check whether the > alignment-related crash is still present [1]? I have bad news, unfortunately. :( firefox crashes (reproduceably) right after launch, and it seems it might be something else: Thread 1 "firefox" received signal SIGSEGV, Segmentation fault. MOZ_CrashOOL (aLine=, aReason=0xf8010a832550 "js::jit::InitProcessExecutableMemory() failed") at /build/firefox-mXaCXs/firefox-62.0~b10/mfbt/Assertions.cpp:33 33 in /build/firefox-mXaCXs/firefox-62.0~b10/mfbt/Assertions.cpp (gdb) bt #0 0x01005948 in MOZ_CrashOOL(int, char const*) (aLine=, aReason=0xf8010a832550 "js::jit::InitProcessExecutableMemory() failed") at /build/firefox-mXaCXs/firefox-62.0~b10/mfbt/Assertions.cpp:33 #1 0xf80106977070 in NS_InitXPCOM2.part.338 () at /usr/lib/firefox/libxul.so #2 0xf801094c35f0 in ScopedXPCOMStartup::Initialize() () at /usr/lib/firefox/libxul.so #3 0xf801094cbcac in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) () at /usr/lib/firefox/libxul.so #4 0xf801094cc194 in XRE_main(int, char**, mozilla::BootstrapConfig const&) () at /usr/lib/firefox/libxul.so #5 0x01006210 in do_main(int, char**, char**) (argc=, argv=0x7fef4a8, envp=0x7fef4b8) at /build/firefox-mXaCXs/firefox-62.0~b10/build-browser/dist/include/mozilla/UniquePtr.h:326 #6 0x01005a98 in main(int, char**, char**) (argc=, argv=0x7fef4a8, envp=0x7fef4b8) at /build/firefox-mXaCXs/firefox-62.0~b10/browser/app/nsBrowserApp.cpp:311 (gdb) info threads Id Target Id Frame * 1Thread 0xf80100042740 (LWP 1552) "firefox" MOZ_CrashOOL (aLine=, aReason=0xf8010a832550 "js::jit::InitProcessExecutableMemory() failed") at /build/firefox-mXaCXs/firefox-62.0~b10/mfbt/Assertions.cpp:33 2Thread 0xf8010dd6f910 (LWP 1573) "Gecko_IOThread" 0xf801009c358c in epoll_wait (epfd=, events=0x71ea600, maxevents=, timeout=) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
Re: Testing Firefox 62 on sparc64
> Could someone with a desktop installed on their sparc64 box please > test the firefox package from experimental and check whether the > alignment-related crash is still present [1]? Many thanks for building it, I will try the package later tonight! > You also should pin down experimental in your /etc/apt/preferences: > > Package: * > Pin: release a=experimental > Pin-Priority: 1 Is that really necessary? I thought experimental had a very low priority by default...
